It's good to see a project focussing on production-grade databases on Kubernetes. Particularly the production grade part.<p>There are 33 open source operators for managing databases on Kubernetes. Out of that list only 3 claim to be production ready.<p>Out of 126 Operators that I've looked into the vast majority are abandoned and unfinished. Most state the project status as Alpha in the readme.<p>Kubedb itself has a version number of 0.8.0 for the operator and very low version numbers for the databases. For example version 0.2.0 for Redis.<p>Version numbers can mean anything but they are usually a good indicator of what the project owner thinks the status is.<p>It would be cool to see a break-down of status and expected dates for milestones for Kubedb.<p>For anyone interested in browsing other Operators I keep a table updated half way down this blog post.<p><a href="https://kubedex.com/operators/" rel="nofollow">https://kubedex.com/operators/</a><p>The project statuses come directly from what the authors have stated. Many beta status projects are being used in production.
I'm wary of the operator model in general, and we haven't had great success using operators to deploy complex stateful services in our clusters. But to be honest we also haven't had great success deploying them using OTS charts from helm stable either. One of our k8s stateful services is a large elasticsearch cluster indexing about 150m events per day, and the chart was forked and heavily modified by us to get it right. I feel that complex stateful services often have enough devils in the details that trying to implement them through an abstraction gets you into trouble. Operators aspire to be a "smart agent" that can translate a CRD resource declaration into a functioning thing, allowing you to implement your data store at an even higher level of abstraction than a helm chart provides. Since in my experience charts are themselves too abstract for this purpose (you either end up forking/modifying or, if the chart actually provides full coverage of the configuration options, creating a whole new hard to comprehend API to the k8s resources you're trying to deploy), I'm not that excited about having a back-end clippie that can do it for us. It's probably fine for simple use cases, and especially those where you often need to create and destroy simple dbs, but imo not yet for large production use cases.
While I have completely embraced running stateless services in Docker, I have been hesitant to migrate the database layer to containers. While I have not tested it personally, I have seen numerous reports of performance issues when using volumes. Is this no longer an issue, or was it limited to bind mounts? Do volumes not use the storage driver? Also, I have run into permission issues when using volumes with Docker, which I'm sure was just my own ignorance but it does seem like a cause for confusion and potential error. I have read through the documentation on the linked page, and the quickstart guides for KubeDB seems great for getting up and running, but I do worry about situations like if an automated PG database failover can't reconcile a timeline, there isn't much documentation on failover at all and this could add significant complexity to something that is already a potential nightmare. Anyone care to share their experiences running production databases in k8s?
For those terrified of an AWS dominated future, projects like this are crucial. The closer we can get to OSS based push button open source DB cluster in any cloud, the less we need fear AWS will host everything and lock us in to a walled garden of closed source AWS systems.
I’ve always been troubled by production-grade handling of state in containers - specifically as it pertains to data backup.<p>This module takes that into account - and defines a “backup k8s object” that will trigger a db dump. But there is still no way to get point in time data recovery/backup that you get from current production-grade managed state providers. Im going to say its production grade if we are using the standards of 10 years ago. Production-grade today, I feel, is a bit more robust.
Interesting project! Thanks for sharing.<p>How does this compare to other community efforts, e.g. Zalandos Patroni project, aside from supporting more databases than just postgres?
Does anyone know of a docker alternative like this? So something like KubeDB that lets me deploy a production-ready postgres db on docker swarm for example?
Funny because I was just baffled by the pricing of HA MongoDB (from formerly mlab), it gets way too pricey way too fast.<p>When looking at the hardware being provisioned I realized it wasn't even anything too crazy and could be had for 1/4 the price at Linode.<p>I will definitely be using this in the future.