Using Percona Everest Operator CRDs to Manage Databases in Kubernetes

Percona Everest is a free and open source tool for running and managing databases like PostgreSQL, MySQL, and MongoDB inside Kubernetes. It simplifies things by providing three ways to work with your databases: a web interface (UI), a set of commands (API), and direct access through Kubernetes itself using built-in tools like kubectl.

Note: Before working with the CRDS shown in this blog, make​​ sure you have Percona Everest installed in your Kubernetes cluster. You can follow the official Percona Everest installation guide.

The Percona Everest Operator is a core component of the Percona Everest platform. It defines a set of Custom Resource Definitions (CRDs) and provides Kubernetes-native abstractions to help you manage your databases declaratively. In this blog post, we’ll take a closer look at the key CRDs offered by Everest and how they fit into the overall architecture.

While we generally recommend interacting with Everest through its API or UI for ease of use and abstraction, there are several scenarios where working directly with CRDs can be advantageous:

• GitOps workflows: Managing infrastructure via Git allows for version-controlled, auditable, and automated deployments using tools like Argo CD or Flux. CRDs integrate naturally into this workflow.
• Advanced customization: Certain low-level or edge-case configurations might not yet be available through the Everest UI or API, but can still be configured directly through CRDs.
• Automation and scripting: Platform engineers often prefer using native Kubernetes tools like kubectl, kustomize, or CI/CD pipelines that apply manifests directly for streamlined automation.

Note: We published the Percona Everest Operator CRD Usage Guide earlier this year. This blog highlights some of the most practical and commonly used aspects of that guide.

    Image: Everest Operator: Key Components and CRDs

1. Define your database with DatabaseCluster

The main CRD you’ll work with is DatabaseCluster. It defines everything about your database: the engine type (like PostgreSQL, MongoDB, or MySQL), the number of replicas, storage size, resource limits, backup settings, and how the database is exposed inside or outside the cluster. You can manage your databases just like any other Kubernetes resource, declaratively and consistently.

Example for a simple PostgreSQL cluster:

Percona Everest currently supports the following database engines:

• postgresql – PostgreSQL
• pxc – Percona XtraDB Cluster (MySQL)
• psmdb – Percona Server for MongoDB

2. Manage database engine versions

The DatabaseEngine CRD represents the installation of a Percona database operator, and it keeps track of:

• Operator installation state
• Available database component versions
• Pending operator upgrades

To check the available versions, use:

This is useful when you want to control which version you install or upgrade to.

3. Backups: Scheduled, on-demand, and point-in-time

Before configuring backups, you need to set up a backup storage location. First, create a Kubernetes secret with your cloud storage credentials:

Then, create a BackupStorage custom resource that references this secret:

Finally, configure backup schedules in your DatabaseCluster:

You can also create on-demand backups using the DatabaseClusterBackup custom resource.

Backups may be restored to a DatabaseCluster using the DatabaseClusterRestore custom resource:

4. Point-in-time recovery (PITR)

Point-in-time recovery lets you restore your database to an exact moment in time, for example, just before something went wrong.

To do this in Percona Everest, you create a DatabaseClusterRestore resource. You specify the name of the backup and the exact time (in UTC) you want to restore to.

You can also monitor the restore status:

5. Monitoring with Percona Monitoring and Management

Percona Everest supports Percona Monitoring and Management (PMM) as its monitoring solution. Before enabling monitoring for your database clusters, you need to create a MonitoringConfig that defines your setup.

First, create a secret with your PMM credentials:

Then create a MonitoringConfig:

Now you can enable monitoring for your database cluster:

6. Additional troubleshooting tips

Use the following command to quickly see the current state of your cluster (e.g., ready, creating, error, etc.):

To get more detailed information about the cluster, including its configuration, recent events, and any possible warnings or errors, use:

If your database cluster is stuck or shows an error, the first place to check is the operator logs. These logs can help you understand if there was a problem applying the CRD or managing the database resources.

Final notes

Using Percona Everest CRDs is a powerful way to manage your databases declaratively within Kubernetes. It’s especially useful for teams adopting GitOps, building automation pipelines, or working on platform engineering.

If you want to explore more examples, the official documentation includes CRD-based setups for PostgreSQL clusters, MySQL (Percona XtraDB Cluster), and MongoDB (Percona Server for MongoDB), including sharded clusters.

Resources

• Full CRD usage guide and examples: here
• Everest source code and YAMLs: Percona Everest repo on GitHub

Feel free to share your experience in our Percona Community Forum.