Show HN: KubeDB – Kubernetes-ready production-grade databases | Hacker News Reader

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

kubedb.com

108 pointstamalsaha00135 comments

Thanks for putting this together, it's great to have something that covers backups and restore and operation all in one package.

I'd recommend updating the name to be more descriptive. Anything xDB sounds like it in itself is a database. That's what I was expecting. KubeDBOperator or similar would let us know: it's related to K8s, it has to do with databases, it likely manages deployments with HA/failover/backups.

As other commenters noted as well, you have to click at least 3 times before you understand what the software does based on the above link. Linking to the home page rather than the welcome would be a better choice for those not currently familiar with your project.

Either way, appreciate all the work that went into this project!

I agree about the confusing naming. They could reverse it: DBKube!

My first impression is that your Concepts > Overview section needs to go on your front page. Because it's not obvious just what the product is.

Other than that, looks cool.

I thought the front page was quite helpful for figuring out what the product was (once I realized the HN link pointed to the documentation page and not the front page).

Ah! I didn't even notice I was not on the front page!

Yeah, don’t feel bad. It took me a while as well.

Same here. I didn't know what the elevator pitch is.

On the other hand, when I looked it up, this sounds like a really interesting project, exposing DBs as application resources.

There is something I remember from CloudFoundry (though I don't know if this is working anymore), and that is with adding in dependencies like databases into the specs for an application.

I kinda wonder if that could be done: add an annotation on a pod spec which the operator can look for and set up the database (if it doesn't exist) and provision credentials.

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.

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.

Can someone explain to me why I'd run this over a StatefulSet of whatever software I want to deploy?

I've been skimming the docs and can't find a good reason TBH.

StatefulSets are not "smart." You would need to manage and configure any kind of replications, leader elections, backups, etc. Operators like KubeDB make this easier to manage, and can make stateful applications more "Cloud Native"

I think the value add is the various "for free" stuff that you get listed here: https://kubedb.com/docs/0.9.0/concepts/what-is-kubedb/overvi...

The Postgres clustering advertised here[0] seems like a great reason to me.

0: https://kubedb.com/docs/0.9.0/guides/postgres/

How does that compare to something like CitusDB I wonder?

It looks like a standard single r/w master + multiple r/o slave topology with the addition of their own leader election. I'd want to understand how the latter works and how it is tested very well before I'd trust it.

https://kubedb.com/docs/0.9.0/guides/postgres/clustering/ha_...

https://github.com/kubedb/postgres/blob/master/pkg/leader_el...

Really nice work!

Question: How are snapshots implemented? Are you using k8s native snapshots (which I think are alpha?) or other?

EDIT: Looks like snapshots are per db feature: https://github.com/kubedb/project/issues/337

Hopefully Kubedb can leverage K8S snapshots when they mature

Thank you! We are using DB specific tools for taking snapshot. Example, mysqldump for MySQL etc. We are looking into k8s native snapshots for future releases. Here is the tracking issue: https://github.com/kubedb/project/issues/337

Is it just me or is the number of clicks required to get a feel for the project ridiculously high? I gave up

are there any docs what you can set for the crd values? I only see some examples but I do not see any full crd api doc.

something like: https://kubernetes.io/docs/reference/generated/kubernetes-ap...

Does anyone know if there are plans for a Cassandra operator? Or is running Cassandra on K8S just not recommended?

https://github.com/instaclustr/cassandra-operator :)

Thanks for the link, do you have experience or feedback on using this?

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.

Is this production worthy?

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.

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

I hear you. The goal of our analytics collection is to know the # of active users of our product. So, we send an event to Google Analytics when a command is run or periodic pings for long running (> 1 hr) commands. You can disable it by setting the flag --enable-analytics=false. You can see further discussion on this matter here: https://github.com/cncf/toc/issues/107#issue-311155675

Lastly, everything is open source. So, you are free to read the code and modify and use your modified version if that's what you prefer. xref: https://github.com/kubedb/operator/blob/0.9.0/pkg/cmds/root....

"To disable stats collection, run the operator with the flag --analytics=false"

+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.

Reply on news.ycombinator.com