MariaDB on Kubernetes
MariaDB on Kubernetes
In short: Running MariaDB on Kubernetes means using the MariaDB Operator to run a Galera Cluster as a StatefulSet. Galera gives you synchronous multi-master replication, with automated SST to recover nodes. PersistentVolumeClaims hold the data, and Pod Disruption Budgets protect quorum during maintenance. MaxScale handles read/write splitting and failover behind one Service. Mariabackup automates backups to object storage.
Deploy production-grade MariaDB on Kubernetes with Galera Cluster and MaxScale integration. You get automated failover and rolling upgrades for mission-critical database workloads.
JusDB architects production-grade MariaDB on Kubernetes deployments utilizing the official MariaDB Operator and MaxScale proxy topologies. JusDB DBREs configure multi-replica Galera StatefulSets, provision local NVMe storage classes, enforce strict PodDisruptionBudgets, and orchestrate rolling upgrades, with incident response at agreed initial-response targets.
Comprehensive MariaDB on Kubernetes Services
We cover MariaDB on Kubernetes from operator deployment through production monitoring. Our solutions are end-to-end and built for cloud-native environments.
MariaDB Operator Deployment
MariaDB Operator setup and configuration for automated Galera Cluster lifecycle management on Kubernetes
- MariaDB Operator installation and setup
- Custom Resource Definition (CRD) tuning
- Galera Cluster bootstrap automation
- RBAC and namespace configuration
Helm Chart Management
Chart customization, values tuning, and upgrade strategies for reproducible MariaDB deployments
- Helm chart customization and templating
- Values file tuning for production
- Chart version upgrade strategies
- GitOps integration with ArgoCD / Flux
Galera Cluster on K8s
Synchronous multi-master Galera Cluster on Kubernetes with automated node recovery and quorum management
- Galera Cluster on K8s setup
- SST and IST configuration
- Pod Disruption Budget planning
- Anti-affinity and topology spread
MaxScale Integration on K8s
MaxScale proxy deployment on Kubernetes for intelligent query routing, read/write splitting, and failover
- MaxScale Deployment on K8s
- Read/write splitting configuration
- Connection pooling and routing
- Automatic failover detection
Monitoring (PMM, Prometheus)
Prometheus, Grafana, and PMM on Kubernetes for full observability of MariaDB Galera clusters
- Prometheus ServiceMonitor setup
- Grafana dashboard provisioning
- PMM on K8s integration
- Alertmanager rules and routing
Backup & DR
Mariabackup on K8s, S3 snapshots, and cross-region restore for comprehensive data protection
- Mariabackup on K8s automation
- S3-compatible snapshot storage
- Scheduled and on-demand backups
- Cross-region restore testing
Why Run MariaDB on Kubernetes?
Cloud-native MariaDB with Galera multi-master replication, MaxScale proxy, and rolling upgrades. We use infrastructure-as-code so deployments stay consistent and repeatable.
Cloud-Native MariaDB
Run MariaDB as a first-class Kubernetes workload with declarative configuration and self-healing. It fits straight into your cloud-native infrastructure and CI/CD pipelines.
Operator-Managed Lifecycle
The MariaDB Operator encodes expert DBA knowledge into automated controllers. Those controllers handle Galera bootstrap, node joining, SST transfers, backup, and failover without manual intervention.
Rolling Upgrades
Rolling update strategies let you upgrade MariaDB versions and apply configuration changes without taking the cluster down. The operator runs graceful node drains and health checks at each step.
Auto-Failover
Galera Cluster provides automatic node recovery and quorum-based failover. MaxScale detects topology changes and reroutes traffic transparently, with the goal of zero application-level disruption.
MariaDB on K8s Key Metrics
MariaDB Kubernetes Operators Compared
Pick the right operator for your MariaDB on Kubernetes deployment. Base the choice on your clustering model, tooling preferences, and scale requirements.
MariaDB Operator
MariaDB Operator
Galera Cluster with MaxScale on Kubernetes
Percona Operator
Percona Operator for MySQL
Galera-compatible MySQL stack (Percona Server for MySQL — not the MariaDB server)
Helm + StatefulSet
Bitnami / Custom Helm
Helm-based MariaDB Galera deployment
Our MariaDB on Kubernetes Implementation Process
A tested methodology for deploying production-ready MariaDB on Kubernetes with comprehensive testing and validation.
Assessment & Planning
Evaluate your workload requirements, existing infrastructure, and Kubernetes environment. Select the right operator, Galera topology, MaxScale configuration, and storage backend.
Operator & Cluster Setup
Deploy the MariaDB Operator via Helm or OLM. Configure Galera Cluster custom resources, MaxScale proxy, and persistent volumes. Then set up networking and security contexts for production readiness.
Migration & Validation
Migrate data from existing MariaDB instances and validate application connectivity through MaxScale. Then run failover and backup/restore tests, and benchmark Galera performance under load.
Production & Operations
Go live with full monitoring, alerting, automated Mariabackup schedules, and runbooks. Provide team training on operator management, day-2 operations, and ongoing support.
How JusDB MariaDB Kubernetes Architecture compares to alternative models.
Generic Kubernetes administrators and legacy outsourced agencies lack deep MariaDB Operator internals, StatefulSet persistent storage guarantees, and rolling upgrade engineering. Here is how our DBREs compare:
| Evaluation Vector | JusDB DBRE | In-House DBA | Legacy Agency | Developer Generalist |
|---|---|---|---|---|
| MariaDB Operator vs Custom Galera StatefulSets | Deploys the official Kubernetes MariaDB Operator with custom CRDs for MariaDB, MaxScale, and Backups, automating cluster bootstrap, state reconciliation, and self-healing. | Maintains brittle manual StatefulSet manifests without custom controllers, requiring manual intervention for node joining and state recovery. | Deploys generic unmaintained third-party Helm charts with hardcoded credentials and broken SST lifecycle hooks. | Runs standalone single-pod MariaDB Deployments with ephemeral storage, losing all data upon container crash or node rescheduling. |
| Multi-AZ Pod Anti-Affinity & Rack Topology | Configures strict topologySpreadConstraints, podAntiAffinity, and zone-aware Galera segment mappings across availability zones so the cluster keeps quorum through the loss of one AZ. | Uses soft preferredDuringScheduling anti-affinity; scheduler co-locates multiple Galera pods on the same Kubernetes worker node during node drains. | Ignores Kubernetes topology awareness entirely; all replicas schedule into a single zone, causing complete downtime during cloud zone outages. | Does not configure node selectors or anti-affinity; multiple replicas land on resource-constrained development worker nodes. |
| Local NVMe StorageClasses & Persistent Volume Expansion | Provisions dedicated local NVMe StorageClasses with XFS filesystem tuning, volume expansion capabilities, and tuned I/O limits to prevent disk stalls during state transfers. | Uses standard network-attached block storage (e.g., EBS gp2) with burstable IOPS, causing severe Galera flow control pauses during I/O starvation. | Over-provisions monolithic cloud disks without volume expansion testing, forcing manual database downtime when storage capacity is exhausted. | Uses default storage classes with hostPath volumes that break when pods reschedule to different Kubernetes nodes. |
| MaxScale Layer 7 In-Cluster Routing & Read/Write Splitting | Deploys in-cluster MaxScale CRD instances with causal consistency, connection pooling, automated failover detection, and headless Kubernetes Service endpoints. | Uses standard Kubernetes ClusterIP Service for round-robin load balancing, sending write queries to desynchronized or joiner nodes. | Routes database traffic through external cloud load balancers or Ingress controllers, adding unnecessary network hops and connection drops. | Directs application pods directly to pod IPs or a single pod DNS name, breaking whenever pods restart or scale. |
| PodDisruptionBudgets (PDB) & Zero-Downtime Rolling Upgrades | Enforces strict PodDisruptionBudgets (maxUnavailable=1) and automated preStop lifecycle hooks to coordinate Galera node drains during zero-downtime rolling upgrades. | Performs cluster updates without PDBs; automated node pool upgrades drain multiple nodes simultaneously, destroying Galera cluster quorum. | Performs manual kubectl delete pod commands without checking wsrep_local_state, triggering cluster-wide split-brain and downtime. | Applies kubectl rollout restart statefulset blindly, taking down all cluster nodes simultaneously and corrupting grastate.dat. |
| Kubernetes Automated Backups, S3 Archival & PITR Drills | Configures mariadb-operator Backup CRDs streaming encrypted mariabackup archives to S3/GCS with automated Cron schedules and continuous PITR drill validation. | Relies on basic Kubernetes CronJobs executing mysqldump into PVC volumes without S3 offloading or point-in-time recovery capabilities. | Uses container snapshot utilities that capture non-quiesced filesystems, producing corrupted InnoDB tablespaces upon restore. | Relies solely on Kubernetes volume snapshots without database quiescing, failing consistency checks during recovery testing. |
Critical MariaDB K8s Outage Modes We Eliminate
Running distributed stateful databases in cloud-native container orchestrators introduces severe availability hazards during automated node drains, CSI volume detach timeouts, and proxy routing desynchronization. Our DBREs resolve these breakdown modes:
Node Drain Eviction Breaking Galera Quorum
Automated Kubernetes cluster upgrades or worker node autoscaling drain multiple database nodes concurrently. Without strict disruption constraints, Galera loses majority quorum (>50%), terminating active database connections and freezing the cluster.
JusDB deploys custom PodDisruptionBudgets (maxUnavailable=1) combined with preStop lifecycle hooks that verify Galera cluster status before pod termination, preventing unsafe multi-node evictions.
Kubernetes Volume Detach Timeout Freezing Pod Restart
When a database node fails, the cloud provider CSI driver hangs on volume detachment or multi-attach error states. The newly scheduled MariaDB pod stays stuck in ContainerCreating, resulting in prolonged node downtime.
JusDB tunes CSI timeout thresholds, configures local NVMe StorageClasses with VolumeBindingMode: WaitForFirstConsumer, and automates volume attachment force-detachment runbooks.
MaxScale In-Cluster Split-Brain Connection Routing
During network partitioning or transient pod restarts, internal MaxScale replicas lose synchronization with Kubernetes endpoints, misidentifying donor or partitioned nodes as valid primary write targets.
JusDB deploys MaxScale via official Operator CRDs with Galera-Monitor integration, readinessProbes verifying wsrep_ready=ON, and causal consistency filters (causal_reads=true).
Our Kubernetes DBREs execute non-blocking CLI telemetry inspections to evaluate operator reconciliation states, pod health, and in-container replication status without disrupting cluster workloads:
Audits MariaDB custom resources, MaxScale proxy pods, and replica status across Kubernetes nodes to verify multi-AZ distribution and operator reconciliation health.
# Check MariaDB operator CRDs, MaxScale proxy status, and pod placement across nodes kubectl get mariadb,maxscale,pods -n mariadb -o wide
Inspects Galera cluster operational state, membership size, and primary component quorum directly inside the primary MariaDB container.
# Query Galera cluster health, size, and primary status inside the running pod kubectl exec -it -n mariadb mariadb-0 -c mariadb -- mariadb -u root -p"$MARIADB_ROOT_PASSWORD" -e "SHOW STATUS LIKE 'wsrep_cluster%';"
MariaDB on Kubernetes — Frequently Asked Questions
Common questions about running MariaDB on Kubernetes in production environments.
Ready to Run MariaDB on Kubernetes?
Let our experts deploy and manage production MariaDB on Kubernetes. We build Galera Cluster, MaxScale proxy, and operator-driven automation around the availability target you set.
Related MariaDB Services
Explore more ways our MariaDB experts can help optimize your database infrastructure
Need a different MariaDB service? Browse our complete offerings.