VSHN Managed MariaDB

Problem

We need to provide MariaDB on Kubernetes with the following features:

  • Standalone and cluster functionality (Galera)

  • Ability to customize MariaDB settings

  • Included metrics exporter

  • Backup

  • Regular Maintenance

  • Version Upgrades

Solutions

For MariaDB there are a few operators available, as well as the various Helm charts.

The following section contains the options that have been looked at and chosen among few others that have been discarded for following reasons:

  • Lack of support for MariaDB

  • Lack of support for MariaDB Galera Cluster

Requirement Bitnami Helmchart mariadb-operator

Standalone

✅

✅

Galera

✅

✅ (Multi master, single master)

Customize MariaDB Settings

✅

✅

Metrics

✅

✅

Backup

❌

✅

Automatic Restore

❌

✅

Regular Maintenance

❌

❌

Version Upgrades

✅

✅

User management

❌

✅

Logical Database Management

❌

✅

Not looked into:

Analysis - mariadb-operator

mariadb-operator/mariadb-operator

As of writing this document a very new Kubernetes operator, which is currently the best what can be found on GitHub. It comes with a variety of installation methods and is actively maintained. It is also mentioned in MariaDB knowledge base: Kubernetes Operators for MariaDB. It uses MIT license[en.wikipedia.org/wiki/MIT_License] which has enough permissions to be used commercially by VSHN. There’s mostly one contributor to the project which makes it rather high risk of orphanage.

Advantages
Disadvantages

  • Lack of regular, automated maintenance

  • Maintained by a single maintainer only, if he leaves the project, we would have to fork and maintain it ourselves

  • Restores database to new instance, like Stackgres does in PostgreSQL, which is not ideal for us, but we can work around it

  • We would need to write and maintain a new Project Syn Commodore Component to deploy this operator

  • Potentially more difficult to move the SPKS project to AppCat

Analysis - Bitnami Helm Chart

Bitnami Helmchart.

Bitnami Helm Charts are solid, actively maintained, and we already have experience integrating it into our offerings. It is not as feature rich as the operator though it has much lower risk of orphanage. Backup and automatic restore will require more time to engineer unlike the operator.

Advantages

  • Supports most of our needs

  • Easy to integrate with VSHN AppCat

  • Sufficient Galera support

  • Well tested and widely used by VSHN

  • Faster integration and development as we already know how to work with it

  • Potentially easier to move the SPKS project to AppCat

Disadvantages

  • Lack of regular, automated maintenance

  • No user or user/logical database management.

  • Neither Backup nor automatic restore

Decision

We use the Bitnami Helm Chart.

Rationale

The mariadb-operator project seems to be a very good solution with high potential, though has a high risk of being abandoned. Also, we would need to invest much more time to integrate it into our offerings and maintain it.

Bitnami’s Helm Chart isn’t that feature rich, but it has a lot of more advantages. Using it, we can offer the same quality for our customers, without taking unnecessary risk and with shorter development time. We’re also using the Bitnami Helm Chart for our Redis offering.

We also agreed to the fact that we should prefer Helm Charts over operators for the following reasons:

  • Helm Chart are readily available for most of our services.

  • We have great experience with Helm Charts.

  • We should stick with one solution as much as possible to reduce complexity.

  • Operators may be very much prone to sudden bugs which may be difficult to fix on our own.