An open-source MySQL alternative for running database on Kubernetes | Hacker News Reader

An open-source MySQL alternative for running database on Kubernetes

github.com

60 pointsTalktoCrystal56 comments

This seems interesting but this passage from the readme is a red flag to me:

>You do not have to learn database tuning. KubeBlocks can leverage storage and computing resources to achieve optimal database performance.

No one has ever delivered on this pipe dream.

I think the key word here is "you".

You just get it running, hack your spaghetti and when it becomes a problem you're already assigned on another project so someone else will have to sort it out.

And that guy is usually me.

Just remember when you leave a pool of shit behind, one of the victims might be making a hiring decision about you at some point in the future.

Read that last part again folks. Twice if you have to. You will run into the same folks in the industry if you last longer than 10 years.

“The industry” extends far beyond and is more than the big tech circle jerk. I’ve bounced around outside of the big tech circus for nearly 15 years now and have -never- unwittingly run into someone I previously worked with. Have I targeted institutions that I know employ people that I've crossed paths with in the past? Yes, deliberately for one reason or another, but never once have I been hired, paged through a company directory and been surprised to the point of "oh, they're here?".

Hey man if I run into the same people again I hope they either understand what my situation was.

People try to do their best.

https://www.sqlite.org/pragma.html#pragma_optimize ?

If SQLite feels that performing database optimizations (such as running ANALYZE or creating new indexes) will improve the performance of future queries, then some database I/O may be done.

So... throw money on compute instead of just adding an index..?

Seems Kubeblocks provids some parameters templates based on their knowledge on databases. To some extent, it will improve performance. Of course, I don't think users will be totally freed from `database tuning`, which is too complex a topic.

I’m offended that you don’t take even 10 minutes to understand why this will not work.

People say they don't need sysadmins and stuff like this is the result.

Vertical scalability limits are very soon met and can be difficult to fix post-fact.

My scepticism was clearly not well enough signalled, apologies.

To be clear I agree "waste money to avoid applying basic database techniques" is A Bad Thing!

It's phrased as a joke, no?

This works when your data fits in L2 cache

Lol glad I’m not the only one who immediately thought “bullshit” when reading that.

At best it becomes someone else’s problem, as others here have said.

Try it and maybe you get a dream-come-true.

So now instead of debugging database performance issues you also have to debug the third party database orchestration middleware and the Kubernetes cluster workloads.

There is always an 'orchestration' middleware in some form, you just can't avoid it. The key is if the benefit it gives overcomes the complexity it introduces.

That is the reason why you need KubeBlocks, it takes over the complexity.

That is not how complexity works. You might lower the difficulty in the happy path, but when something goes wrong, there is additional complexity, and that means more places to debug and understand.

This is my primary objection to 3rd party kubernetes operators. I really don't care how hard something is to setup or learn to manage. I care how hard it is to recover, tune, and scale.

> when something goes wrong

Thank for correctly stating “when,” not “if”.

Abstractions are wonderful until they aren’t, at which point you’d better know how everything underneath them works.

I thought that the point was the solution architecture also guarantees increased complexity.

If this is supposed to be used in production as open source, then I am a little surprised that it's under AGPL 3.0, especially given there's no mention of commercial version.

Depending on one's needs and interests, they changed it from Apache 2 a few months ago: https://github.com/apecloud/kubeblocks/blob/5ba9b39716940cd7... I didn't dig into the changes to see if there's anything super interesting that happened between then and now

It really, really jams me up that the GitHub license thing is so stupid that when looking at a file containing the Apache 2 license it continues to say AGPL right across the top of that file. It's so misleading. Their license sniffer always shows $default_branch/LICENSE regardless of what branch (or file) one is looking at

Unless you were using a modified version without making your changes available, why would this be a problem?

AGPL is viral, requiring you open source of all source involved in serving network clients, not only this AGPL software itself.

It's meant to close the serve-over-the-network loophole of the GPL.

thats only true if you use the code in a serving application.

If the SDK to connect is GPL and the backend service itself (never exposed to a user) is AGPL then you're fine.

I like the AGPL. The intent of AGPL is to encourage openness and collaboration, not to restrict or burden software developers. Many great projects choose this AGPL.

>An open-source MySQL alternative for running database on Kubernetes

Very confusing title. It made me think it's some kind of open-source database compatible with MySQL (and kind of implies that MySQL isn't open-source).

It seems it's a tool for managing databases in Kubernetes.

Yep, a DoK(Data on K8s) solution.

After looking at the readme, I'm still unclear on what kind of product it is - another database operator? In the readme I don't see any advantages it has compared to other operators, why not I choose other more mature operators?

Are the "Goals" serious? That looks more like empty slogans. Perhaps it would be better to explain in detail what it have actually done and how did it.

Furthermore, when can change that misleading title?

I like the message it conveyed 'No need to be a K8s professional'. That is exactly how I feel after creating a mysql cluster smoothly. I tried oracle mysql opertor months earlier, but failed to install it on AWS EKS without knowing why.

This "why you need KubeBlocks" reads like a bunch of pointless marketing speak (quoted below).

" >Why you need KubeBlocks When adopting a multi-cloud or hybrid cloud strategy, it is essential to prioritize application portability and use software or services that offer consistent functionality across different infrastructures."

I'd rather read some concrete examples or use cases.

Is it just me, or are the comments on this post swarming with people that seem to only talk about this particular product. This feels like a borderline coordinated self promotion effort with several new/young accounts speaking highly positively in contrast to what seems like some reasonable skepticism of a product.

AIUI emailing hn@ycombinator.com (via the Contact link at the bottom of every page) to bring shilling to their attention is always welcome, and I'm pretty sure dang takes steps if he finds evidence

There are also other k8s operators such as KubeDB.

I agree deeply.

It looks like this project is for more than just MySQL. Should the title get updated?

Also, the `Quick Start` link in the readme goes to a 404.

@dang: can the title be un-editorialized to remove "MySQL" and "alternative"? That doesn't make sense since it orchestrates MySQL (and other DBMS).

Maybe use the first sentence of the README:

> KubeBlocks is an open-source Kubernetes operator that manages relational, NoSQL, vector, and streaming databases on the public cloud or on-premise

Sorry about that. Fixed now.

The animated screenshot looks promising. I'd like to try it out. What's a good way to get SQL dumps inside the cluster? On the overview page there's a diagram for production deployment that includes a LoadBalancer for external clients. What Loadbalancer can I use that can proxy the MySQL protocol?

If you refer to backup, KubeBlocks provides ways to do backup with disk snapshot(supported from cloud provider like AWS EBS), file backup with tools such as xtrabackup for MySQL, wal-g for PostgreSQL. For SQL dump, a relative dump tool is recommended, such as mysql_dump for MySQL, you can dump it from the outside as a client, also, the built-in routine SQL dump will be supported in the near future. Anyway, KubeBlocks tries to integrate the best practices for any database product, the solution either provided by a well-known database provider or by an individual contributor, or by KubeBlocks official as you see from a fresh start. LoadBalancer is implemented with integrations of well-known cloud providers' LB controllers, it works in layer 4, so it can route any tcp traffics. When referring to MySQL proxy, KubeBlocks integrates vitess as proxy for apecloud-mysql(an addon in KubeBlocks, try 'kbcli addon list'), please try it out and enjoy yourself.

I had been keeping an eye on this project before, and upon checking it out recently, I've noticed many minor improvements. It's not just that one operator now supports multiple engines, but the feature experiences of several engines have also gradually become more well-rounded.

And their command line `kbcli` did impressed me, very easy to use. kbcli helps me create various clusters in several minutes. I have been working on mysql developing for more than five years, and I guess the ApeCloud team are very experienced in operating at least mysql.

I'm still not sure what is the purpose of this, the README is not clear.

treat it as a project to ease DoK(Data on K8s).

It looks like a fully managed database service alternative. MySQL, PostgreSQL, Redis, MongoDB... all the popular db engines.

There are docs for Postgresql and Kafka, but they do not look as fleshed out. Are those production-ready?

Yes, already included in the new release.

The title is misleading and made me think there was a new open source database.

It seems that this can not only manage databases but also support Kafka and Pulsar.

Yes, RDBMS, NoSQL, streaming and analytical systems are all supported.

Like the way you make HA visible in the format of lovely cats.

As we know, although Kubernetes (K8s) can be used to build and deploy various applications, including databases, there are still some challenges and limitations related to databases that cannot be fully addressed. Here are some of these issues:

1. Data Consistency: Kubernetes does not directly provide guarantees for data consistency in databases, while databases typically require integrity and consistency of data. This may rely on mechanisms such as database replication, sharding, and transactions to ensure data consistency, rather than solely relying on Kubernetes.

2. Data Persistence and Performance: While Kubernetes provides solutions for persistent storage, such as Persistent Volumes (PVs), it may still not fully meet the requirements of high-performance databases, such as large-scale data processing or high-concurrency workloads in relational databases.

3. Distributed Deployment and Maintenance of Databases: Distributed databases often require data synchronization and load balancing among different nodes. Kubernetes can provide partial support, such as StatefulSets for managing stateful applications, but the distributed nature and complexity of databases may require additional configuration and management to ensure data consistency and high availability.

4. Database Scaling and Fault Recovery: In large-scale applications, databases may need horizontal scaling and fault recovery capabilities. While Kubernetes can dynamically scale and manage containers, scaling and fault recovery at the database level may require more complex configuration and strategies, depending on the specific database engine and architecture.

5. Database Backup and Recovery: Backup and recovery are critical tasks in database management. Although Kubernetes provides snapshot and backup functionality, the backup and recovery process for databases may require additional considerations, such as handling transaction logs and ensuring data consistency.

While Kubernetes provides some convenience and abstraction layers for building databases, the above issues indicate that specialized database architectures and solutions are still required for specific database requirements and scenarios to meet the needs of data consistency, persistence, performance, and scalability.

I have been downloaded kubeblocks and running it on local k8s, AWS EKS, GCP GKE, it can create many kind of databases very quickly. Also, kubeblocks includes day2 operations keep me free from tons of DBA jobs.

I will keep trying kubeblocks. When the day it meet the needs of data consistency, persistence, performance, and scalability, go production and take a good sleep.

Please don’t parrot ChatGPT outputs without at least citing it.

Yes sure,thanks for your remind. ChatGPT should be cited, and take a cup tea.

Reply on news.ycombinator.com