Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
The aim of developing this operator was solving the problems that I've mentioned but it was also a very good oportunity to get my hands dirty with kubebuilder, the learning experience was quite valuable. Feel free to have a look, any feedback will be very appreciated: https://github.com/mmontes11/mariadb-operator
So, first of all, why MariaDB? When you think about a cloud native database the first think that will probably come to your mind will probably be CockroachDB or a managed offering like RDS, but ... what if your application is not compatible with CockroachDB, you don't want to pay for a managed service but you still want the first-class Kubernetes experience?
That was my case actually... I'm running multiple instances of Photoprism in my bare metal Kubernetes cluster, which uses MariaDB as a database to persist the model, so I needed an automated way of running and operating those intances at scale. The first option was using the bitnami helm chart for MariaDB, which works reasonably well, but I wanted a better Kubernetes experience that allowed me to decrease the burden of maintainability and fully manage the state of the database using CRDs.
Being able to declare how to run and operate MariaDB is a key feature for me, as this will allow me to place those CRDs in a Git repository and continuously reconcile them using Flux. This will be specially helpful if I decided to run more Photoprism tenants in the future or even have multiple Kubernetes clusters.
That was my case actually... I'm running multiple instances of Photoprism in my bare metal Kubernetes cluster, which uses MariaDB as a database to persist the model, so I needed an automated way of running and operating those intances at scale. The first option was using the bitnami helm chart for MariaDB, which works reasonably well, but I wanted a better Kubernetes experience that allowed me to decrease the burden of maintainability and fully manage the state of the database using CRDs.
The aim of developing this operator was solving the problems that I've mentioned but it was also a very good oportunity to get my hands dirty with kubebuilder, the learning experience was quite valuable. Feel free to have a look, any feedback will be very appreciated: https://github.com/mmontes11/mariadb-operator
Related posts
- Question for declarative GitOps managed shops
- 5-Step Approach: ProjectSveltos Event Framework for Kubernetes Deployment with Cilium Gateway API
- Weaveworks Is Shuting Down
- 5-Step Approach: Projectsveltos for Kubernetes add-on deployment and management on RKE2
- Complexity by Simplicity - A Deep Dive Into Kubernetes Components