Percona XtraDB Cluster Operator: a MySQL cluster as a Kubernetes resource

A database cluster expressed as a custom resource

The Percona Operator for MySQL based on Percona XtraDB Cluster automates the creation and management of highly available, enterprise ready MySQL database clusters on Kubernetes. The README is explicit that it encodes the vendor's own best practices for deploying and configuring Percona XtraDB Cluster instances in a Kubernetes environment, on premises or in the cloud.

The implementation is built on the Operator SDK and leverages Kubernetes primitives, which the README frames as following best CNCF practices. That is the standard shape for this kind of tool: you describe the cluster you want in a custom resource, and a controller in the cluster reconciles reality towards that description, handling the pod lifecycle, the replication topology and the failover behaviour that a StatefulSet on its own cannot express.

The capability list tells you what the operator is actually managing. Easy deployment with no single point of failure. Load balancing and a proxy service with either HAProxy or ProxySQL. Scheduled and manual backups. Integrated monitoring with Percona Monitoring and Management. A Smart Update feature to keep the database software up to date automatically. Automated Password Rotation, which uses the standard Kubernetes API to enforce password rotation policies for the system user. And support for private container image registries.

That last group of items, the backups, the monitoring integration and the update automation, is what separates this from a set of manifests. It is a platform, and adopting it means adopting that platform's operating model as well as its software.

Two kubectl apply commands, then a custom resource

The quickstart in the README is deliberately short, because the heavy lifting is in the custom resource rather than in the operator installation.

First you deploy the operator itself from the bundle manifest:

kubectl apply -f https://raw.githubusercontent.com/percona/percona-xtradb-cluster-operator/main/deploy/bundle.yaml

Then you deploy the database cluster itself from the custom resource manifest:

kubectl apply -f https://raw.githubusercontent.com/percona/percona-xtradb-cluster-operator/main/deploy/cr.yaml

Two applies, and the second one is the interesting artifact. cr.yaml is a PerconaCluster custom resource, which means the whole topology of your database, the number of members, the proxy configuration, the backup settings and the image, is expressed as data in a YAML file rather than as a set of Kubernetes objects you assemble yourself.

The repository layout supports that model. There is a config directory holding the CRD bases, a deploy directory with the rendered manifests, a pkg directory with the controller logic, a cmd directory for the operator binary, a clientcmd directory, an installers directory, a build directory and an e2e-tests directory. The Makefile has a generate target that runs go generate and then controller-gen to produce the CRDs and the RBAC files, and a rule that builds deploy/crd.yaml with kustomize from config/crd.

The same directory also holds deploy/operator.yaml, and the Makefile rewrites the image reference inside it with sed to match the version you are building, which is how a fork or a local build gets its own image tag.

The dependency list tells you what the operator talks to

The go.mod file is the clearest description of the operator's real scope, because every entry is a system the operator has to talk to.

The Kubernetes side is the controller-runtime stack at sigs.k8s.io/controller-runtime v0.24.1, with the client libraries at k8s.io/api, apimachinery, client-go, apiextensions-apiserver and component-base all at 0.36.1. The module targets Go 1.26.0, which is a signal about the age of the toolchain assumptions.

Outside Kubernetes, the dependencies map onto the operator's features. The go-sql-driver/mysql and Azure SDK for Go storage azblob, plus minio-go and the Percona version service API, cover the storage and version interactions behind backups and object storage. cert-manager appears as a direct dependency, which is how TLS certificates for the cluster are issued and rotated. Prometheus client_golang is there for the monitoring integration, robfig/cron is the scheduler behind the scheduled backups, and the gRPC and protobuf libraries are the transport between the operator and the components it manages.

The logging and configuration choices are also visible: go.uber.org/zap with go-logr, the caarlos0/env and kelseyhightower/envconfig packages for environment based configuration, pongo2 as a template engine, go-ini for configuration files, and ginkgo with gomega and stretchr/testify for the test suites.

For a reviewer, that list is more informative than the feature bullets, because it shows the operator reaches into the cluster's certificate lifecycle, into object storage for backups, into Prometheus for metrics and into a scheduled job system, and each of those is a dependency version you will have to keep current.

Smart Update and password rotation are the differentiating features

Two of the capabilities are worth separating from the rest, because they are the ones a team would otherwise build itself.

Smart Update is described as keeping your database software up to date automatically. In a replicated MySQL cluster, a version upgrade is not a rolling restart of a Deployment, because the nodes have a replication relationship and a version skew between them is a data correctness problem rather than a deployment inconvenience. An operator that understands the topology can order the upgrade so that replication is never broken, and that is the value here.

Automated Password Rotation uses the standard Kubernetes API to enforce password rotation policies for the system user. The phrase to notice is standard Kubernetes API, because it means the rotation is expressed as a policy the cluster already knows how to enforce, rather than as a cron job in a container that nobody notices when it stops running. It is the kind of feature that shows up in an audit as a control rather than as a convenience.

Private container image registries are listed in the same block, which matters for organisations that cannot pull database images from a public registry. The proxy layer is configurable between HAProxy and ProxySQL, so you choose the one your operational tooling already understands.

The remaining item, integrated monitoring with Percona Monitoring and Management, is the one with the sharpest edge for an evaluation: it is an integration with a specific commercial monitoring product, and the README does not describe what the operator does if you are not running that.

Everest for a web interface, kubectl for everything else

The README notes that while the operator is primarily managed through the command line, you can also use Percona Everest for a web based user interface. Everest is described as an open source tool that provides a streamlined experience for provisioning and managing your databases, simplifying day to day tasks and reducing administrative overhead, with its own documentation and a quickstart guide.

That division is worth understanding before you install anything. The operator is the thing that runs in the cluster, and it is driven by the custom resource and by kubectl. Everest is a separate open source front end that sits on top and talks to the operator. If you install only the operator, your interface is kubectl and the custom resource; if you want a console, Everest is the add-on, and it is a second piece of software with its own lifecycle.

The support structure in the README is also split in a way that matters for planning. There is commercial support, described as enterprise grade assistance for mission critical MySQL deployments, with expert guidance for complex tasks such as multi cloud replication, database migration and building platforms, and there is community support through the Percona forum for general questions, troubleshooting and sharing feedback. The project itself is open source under the Apache 2.0 licence, as the badge in the header shows, and the operator image is published on Docker Hub as percona/percona-xtradb-cluster-operator.

For a project of this size, the split between what the open source operator does and what the commercial support engagement covers is the normal arrangement, and it is the kind of thing your organisation should price in rather than discover later.

Contributing, roadmap and where bugs go

The repository has the full apparatus of a maintained community project. There is a contribution guide at CONTRIBUTING.md, a Building and Testing Guide in the e2e-tests directory, a code of conduct, a Jenkinsfile, a Makefile, a .golangci.yml for linting, an AGENTS.md and a CLAUDE.md, and a public roadmap hosted as a GitHub project.

The roadmap is open for contribution under published guidelines, which is worth noting because it tells you where the vendor wants the operator to go rather than leaving you to guess.

Bug reports have two routes, and the distinction is deliberate. If you find a bug in the Percona Docker images or in one of the related projects, the README says to submit a report to the JIRA issue tracker under the K8SPXC project. For this repository itself, you create a GitHub issue. The learning more about submitting bugs, feature ideas and improvements section points back at the contribution guide.

The Makefile shows how the project is built and tested. The image name and tag are derived from the git branch name, lowercased and with separators turned into dashes, so a branch produces a matching image tag. There is a help target that parses the Makefile itself to list the available commands, the generate target for CRDs and RBAC, and a rule for the CRD manifest built with kustomize.

The test setup is also visible. The Makefile pins ENVTEST_K8S_VERSION to 1.34.1, with a comment explaining that a fixed version is used because on GitHub Actions the latest tag sometimes resolves to an older or incompatible version, causing test or pipeline failures, and it pins ENVTEST_VERSION to release-0.23. The ginkgo and gomega dependencies in go.mod are the test frameworks behind that suite, and the e2e-tests directory is where the end to end coverage lives.

A busy release line and a recent commit stream

On maintenance, the numbers are good. The recent releases are v1.20.0 on 2026-06-05, v1.19.1 on 2026-04-16 and v1.19.0 on 2026-01-19, so the minor version line moves roughly every two to three months with patch releases in between. The last push to the repository was on 2026-10-20, the repository is not archived, and the topic tags include hacktoberfest, which is a sign that the project recruits outside contributions on a schedule.

The licence is the usual one for a Percona infrastructure project, with the Apache 2.0 badge in the README header and the LICENSE file in the repository root. The platform metadata classifies the licence as a custom one that the hosting platform cannot categorise, which usually reflects the file having a form the classifier does not recognise, so the file itself is the text that matters and your legal team should read it rather than the badge.

The documentation is hosted on Percona's own site, with separate pages for the architecture and design decisions and for the operator documentation, and the README points at the Kubernetes operator for PXC index page as the main entry point. The homepage in the repository metadata points at the same documentation.

What the README does not cover is the operational detail you will want: it does not list the supported Kubernetes versions beyond what the dependencies imply, does not describe the upgrade path between operator minor versions, and does not say what happens to an existing cluster when the operator is upgraded. Those are the questions to take to the support channels before you put a production database on it.

Editorial conclusion

Adopt the Percona XtraDB Cluster Operator if you run MySQL on Kubernetes and want a stateful database with replication, proxying and backups managed as a declarative resource rather than by hand, and you are prepared to work with an operator that ships its own opinions about topology. Do not adopt it for a single instance or a non MySQL workload, and do not adopt it if you need a vendor neutral layer, since the operator is specific to Percona XtraDB Cluster and its own monitoring stack. Verify first which Kubernetes API version your cluster runs, because the module targets Go 1.26 and the Kubernetes libraries at 0.36.1, and check the operator's requirements for certificate management and the proxy layer, HAProxy or ProxySQL, before you commit to a topology.

Frequently asked questions

Official sources

1. Issues
2. percona/percona-xtradb-cluster-operator on GitHub
3. Project website
4. README
5. Releases