How RadonDB MySQL Operator Simplifies MySQL Deployment on Kubernetes

Background

With the maturity of cloud‑native technologies, the demand for running MySQL on Kubernetes (K8s) is increasing. Deploying MySQL on K8s reduces operational complexity and improves resource utilization.

This series uses the RadonDB MySQL Operator as an example to show how to design and implement an operator based on a proven MySQL high‑availability solution.

Design Goals

The goal is to enable RadonDB MySQL to run in Operator mode, supporting installation, deployment, and management on Kubernetes and KubeSphere, and automatically performing tasks related to a RadonDB MySQL cluster.

MySQL on K8s Deployment Topology

The topology consists of two parts: a MySQL primary‑replica cluster and a Xenon management cluster that implements the Raft leader election protocol. Each Pod contains MySQL, Xenon, Slowlog, and Metrics containers; Xenon manages the MySQL instance inside the Pod.

Each Pod role diagram (main containers only):

RadonDB MySQL Operator Architecture

In Kubernetes, an Operator is a combination of a Custom Resource Definition (CRD) and a controller.

Operator component design:

Role management (RBAC): uses kube‑rbac‑proxy to interact with the Kubernetes API for RBAC authentication.

Manager: a set of custom controllers, including the most important controller that creates/updates RadonDB MySQL clusters via Custom Resources.

Custom Resources: describe the basic information for building a RadonDB MySQL cluster.

Service: provides read‑write separation with a Leader Service for read‑write traffic and a Follower Service for read‑only traffic, plus ServiceAccount and Headless Service for stable virtual IPs.

Conclusion

The overview above presents the RadonDB MySQL Operator architecture and design thinking. The next article will dive into source‑code analysis, covering scaffold selection, cluster Spec definition, and Status definition.