MySQL on Kubernetes
MySQL onKubernetes
In short: Running MySQL on Kubernetes means using an operator — Percona Operator (XtraDB Cluster/Galera), Oracle MySQL Operator (InnoDB Cluster with Group Replication), or Vitess for sharding — to run MySQL as StatefulSets with PersistentVolumeClaims. The operator automates failover, rolling upgrades, ProxySQL/MySQL Router routing, and XtraBackup-based backups for HA.
Deploy production-grade MySQL on Kubernetes with operator-managed lifecycle, automated failover, rolling upgrades, and cloud-native scaling for mission-critical database workloads.
JusDB provides production cloud-native MySQL on Kubernetes engineering using Oracle MySQL Operator and Percona XtraDB Cluster. Certified DBREs architect direct local NVMe storage with dedicated XFS volume mounts, sub-10s quorum failover, multi-AZ anti-affinity with PodDisruptionBudgets, and automated continuous XtraBackup S3/GCS archival under contractual 15-minute Sev-1 response SLAs.
Services
Comprehensive MySQL on Kubernetes Services
From operator deployment to production monitoring, we provide end-to-end MySQL on Kubernetes solutions for cloud-native environments.
Operator Deployment
Percona Operator, Oracle MySQL Operator setup and configuration for automated MySQL lifecycle management
- Percona Operator for MySQL (PXC) setup
- Oracle MySQL Operator installation
- Custom Resource Definition (CRD) tuning
- RBAC and namespace configuration
Helm Chart Management
Chart customization, values tuning, and upgrade strategies for reproducible MySQL deployments
- Helm chart customization and templating
- Values file tuning for production
- Chart version upgrade strategies
- GitOps integration with ArgoCD / Flux
High Availability on K8s
InnoDB Cluster, Group Replication, and Galera on Kubernetes with automated failover
- InnoDB Cluster on K8s setup
- Group Replication configuration
- Pod Disruption Budget planning
- Anti-affinity and topology spread
Storage & Persistence
PVCs, StorageClasses, CSI drivers, and backup volumes for durable MySQL data on Kubernetes
- PVC and StorageClass configuration
- CSI driver setup (EBS, PD, Ceph)
- Volume expansion and snapshots
- Backup volume provisioning
Monitoring on K8s
Prometheus, Grafana, and PMM on Kubernetes for full observability of MySQL clusters
- Prometheus ServiceMonitor setup
- Grafana dashboard provisioning
- PMM on K8s integration
- Alertmanager rules and routing
Backup & Disaster Recovery
Percona XtraBackup on K8s, S3 snapshots, and cross-region restore for data protection
- Percona XtraBackup on K8s
- S3-compatible snapshot storage
- Scheduled and on-demand backups
- Cross-region restore testing
Why Kubernetes
Why Run MySQL on Kubernetes?
Cloud-native MySQL with operator-managed lifecycle, rolling upgrades, auto-scaling, and infrastructure-as-code for consistent, repeatable deployments.
Cloud-Native MySQL
Run MySQL as a first-class Kubernetes workload with declarative configuration, self-healing, and seamless integration with your cloud-native infrastructure and CI/CD pipelines.
Operator-Managed Lifecycle
Kubernetes operators encode expert DBA knowledge into automated controllers that handle provisioning, configuration, scaling, backup, and failover without manual intervention.
Rolling Upgrades
Upgrade MySQL versions and apply configuration changes with zero downtime using rolling update strategies. Operators orchestrate graceful switchovers and health checks at each step.
Auto-Scaling
Scale MySQL read replicas horizontally by updating a single field in your custom resource. Vertical Pod Autoscaler adjusts CPU and memory based on real usage patterns.
MySQL on K8s Key Metrics
Operators
MySQL Kubernetes Operators Compared
Choose the right operator for your MySQL on Kubernetes deployment based on your clustering model, tooling preferences, and scale requirements.
Percona Operator for MySQL
Percona XtraDB Cluster (PXC) with Galera
Oracle MySQL Operator
MySQL InnoDB Cluster with Group Replication
Vitess
Cloud-native horizontal sharding for MySQL
Process
Our MySQL on Kubernetes Implementation Process
A proven methodology for deploying production-ready MySQL on Kubernetes with comprehensive testing and validation.
Assessment & Planning
Evaluate your workload requirements, existing infrastructure, and Kubernetes environment. Select the right operator, storage backend, and high-availability topology.
Operator & Cluster Setup
Deploy the chosen operator via Helm or OLM. Configure custom resources, StatefulSets, persistent volumes, networking, and security contexts for production readiness.
Migration & Validation
Migrate data from existing MySQL instances, validate application connectivity, perform failover and backup/restore testing, and benchmark performance under load.
Production & Operations
Go live with full monitoring, alerting, automated backups, and runbooks. Provide team training on operator management, day-2 operations, and 24/7 support.
How JusDB Cloud-Native DBRE compares to alternative approaches.
Operating stateful MySQL clusters on Kubernetes without dedicated DBRE operator management risks Group Replication quorum loss, persistent volume CSI detachment deadlocks, and router split-brain routing. Here is how our certified cloud-native engineering compares:
| Vector | JusDB | Cloud Native Default | Traditional Agency | In-House / DIY |
|---|---|---|---|---|
| Oracle MySQL Operator vs Percona Server for MySQL Operator Architecture | Workload-driven operator architecture (Percona Operator for MySQL/PXC for synchronous multi-master Galera clusters or Oracle MySQL Operator for native InnoDB Cluster & Group Replication); custom CRD tuning, declarative mutation hooks, and automated schema migrations. | Generic operator deployment using defaults without CRD customization, memory parameter calibration, or workload-specific connection pooling. | Attempts to deploy MySQL as a naked StatefulSet without an operator, leading to manual failovers, configuration drift, and broken replication. | Basic Helm chart installation from community repos without deep operator expertise, resulting in unmaintained CRD versions and broken upgrades. |
| Direct Local NVMe StorageClasses with Dedicated XFS VolumeMounts | High-IOPS direct-attached local NVMe storage using TopoLVM or local-path-provisioner, formatted with XFS (noatime, nodiratime) and isolated dedicated volumes for datadir and binlogs/redo logs to eliminate IOPS throttling. | Standard network-attached cloud block storage (gp3 / pd-ssd) subject to cloud hypervisor attach/detach race conditions and I/O latency spikes. | Single shared PersistentVolume for data and binary logs on network storage, causing checkpoint stalls and replication latency spikes. | Uncalibrated default StorageClass provisioning with no I/O tuning; susceptible to node evictions corrupting local hostPath mounts. |
| Group Replication / Galera In-Cluster Failover with Sub-10s Quorum Recovery | Automated distributed consensus failover via in-cluster Group Replication Paxos or Galera wsrep with sub-10s failover latency, split-brain elimination, and transparent ProxySQL / MySQL Router connection rerouting. | Standard Kubernetes liveness/readiness probe failover taking 60-120 seconds, risking multi-pod leader elections during network partitions. | Manual failover scripts or unmanaged replication switchovers requiring SSH access and human intervention during production outages. | DIY failover scripts triggered by Kubernetes probe failures, causing repeated cascading restarts and split-brain write corruption. |
| Multi-AZ Failure Domain Anti-Affinity & PodDisruptionBudgets | Strict inter-pod anti-affinity topology spread across availability zones, paired with fine-grained PodDisruptionBudgets (maxUnavailable: 1) and preStop graceful switchover hooks to guarantee quorum. | Loose soft anti-affinity allowing multiple database pods to schedule onto the same Kubernetes node or availability zone during cluster restarts. | Missing PodDisruptionBudgets entirely; automated cluster node upgrades terminate multiple replicas simultaneously. | Basic node selectors without disruption budgets; Kubernetes node drains and autoscaling events trigger catastrophic cluster-wide outages. |
| Automated Continuous XtraBackup Archival to S3/GCS Object Storage | Continuous physical non-blocking backups via Percona XtraBackup or MySQL Shell dump utilities streamed to S3/GCS with client-side AES-256 encryption, lifecycle retention policies, and automated weekly PITR restore drills. | Kubernetes volume snapshots only, lacking non-blocking hot transaction capture and granular point-in-time recovery capabilities. | Cron-based mysqldump scripts executing inside containers, locking tables and storing unencrypted dumps on ephemeral pod disks. | Manual snapshots taken sporadically; backup archives remain untested until a real disaster occurs. |
| Contractual <15-Min Sev-1 Response SLA with Principal DBREs | Contractual, financially-backed <15-minute Sev-1 response SLA with dedicated principal DBREs directly on call 24/7/365, with integrated Prometheus/Grafana alerting and proactive triage. | Community GitHub issues or basic cloud provider ticket queues with 8-24 hour initial triage times and no MySQL internals expertise. | Generic sysadmin tier-1 ticketing helpdesk with 2-4 hour response times and outsourced off-hours shifts. | Single internal engineer on pager duty experiencing alert fatigue and burn-out during high-stress off-hours database incidents. |
Kubernetes Failure Modes
Critical MySQL on Kubernetes Risks We Eliminate
Operating stateful MySQL database clusters inside containerized Kubernetes environments introduces quorum consensus, CSI storage attachment, and router split-brain failure vectors. We engineer resilience into every layer to eliminate these production risks:
Node Drain Eviction Breaking Group Replication Quorum
Kubernetes node autoscalers or automated worker node upgrades drain nodes hosting MySQL cluster pods concurrently when PodDisruptionBudgets are missing. Quorum drops below majority, halting Group Replication Paxos or Galera wsrep consensus, resulting in cluster-wide write stalls and emergency node fencing.
JusDB enforces strict PodDisruptionBudgets (maxUnavailable: 1), multi-AZ topologySpreadConstraints with podAntiAffinity, and preStop lifecycle hooks that orchestrate graceful primary switchovers and quorum checks before allowing node cordon and drain cycles.
CSI PersistentVolume Detach Hanging Pod Rescheduling
When a MySQL pod crashes or reschedules after worker node termination, cloud CSI drivers (AWS EBS, GCP Persistent Disk, or Azure Disk) experience attach/detach race conditions, hanging the PersistentVolume in VolumeInUse status while the replacement pod sits stuck in ContainerCreating.
JusDB deploys direct local NVMe storage classes with TopoLVM or local-path-provisioner for zero-detach failover latency, or implements tuned CSI VolumeAttachment timeout controllers with automated force-detach reconciliation runbooks.
Router Split-Brain During Network Jitter
Transient network partitions or inter-zone latency spikes cause MySQL Router or ProxySQL to misidentify primary status, routing write queries to demoted read replicas or splitting writes between diverging members, triggering read-only transaction errors or severe data divergence.
JusDB configures aggressive quorum health checks via performance_schema.replication_group_members, tightens router failover timeouts, and enforces single-writer fencing policies with automatic super_read_only traps.
Our DBREs execute non-blocking diagnostic commands across Kubernetes CRD controllers and internal MySQL performance schema tables to audit cluster topology, pod distribution, and replica synchronization health:
Audits custom resource controller status, InnoDBCluster reconciliation state, pod distribution across worker nodes, and PVC volume mount health.
# 1. Audit MySQL InnoDBCluster custom resource and wide pod topology kubectl get innodbclusters,pods -n mysql -o wide
Queries performance_schema.replication_group_members to verify member role (PRIMARY vs SECONDARY), member state (ONLINE, RECOVERING, UNREACHABLE), and version consistency.
-- 1. Inspect replication group member states and primary role assignment SELECT MEMBER_ID, MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE, MEMBER_VERSION FROM performance_schema.replication_group_members;
MySQL on Kubernetes — Frequently Asked Questions
Common questions about running MySQL on Kubernetes in production environments.
Ready to Run MySQL on Kubernetes?
Let our experts deploy and manage production MySQL on Kubernetes with operator-driven automation, persistent storage, and 99.99% uptime.