Scale Percona Distribution for MySQL on Kubernetes¶

One of the great advantages brought by Kubernetes platform is the ease of an application scaling. Scaling an application results in adding or removing the Pods and scheduling them to available Kubernetes nodes.

Scaling can be vertical and horizontal. Vertical scaling adds more compute or storage resources to MySQL nodes; horizontal scaling is about adding more nodes to the cluster. High availability looks technically similar, because it also involves additional nodes, but the reason is maintaining liveness of the system in case of server or network failures.

Vertical scaling¶

Scale compute resources¶

The Operator deploys and manages multiple components, such as Percona Server for MySQL, Orchestrator, HAProxy or MySQL Router and others. You can manage CPU or memory for every component separately by editing corresponding sections in the Custom Resource. We follow the structure for requests and limits that Kubernetes provides .

For example, you can add more resources to your HAProxy nodes by editing the following section in the Custom Resource:

spec:
  ...
  proxy:
    haproxy:
      ...
      resources:
        requests:
          memory: 4G
          cpu: 2
        limits:
          memory: 4G
          cpu: 2

Use our reference documentation for the Custom Resource options for more details about other components.

Scale storage¶

Kubernetes manages storage with a PersistentVolume (PV), a segment of storage supplied by the administrator, and a PersistentVolumeClaim (PVC), a request for storage from a user.

Starting with Kubernetes v1.11, a user can increase the size of an existing PVC object (considered stable since Kubernetes v1.24). The user cannot shrink the size of an existing PVC object.

Starting from the Operator version 0.11.0, you can scale Percona Server for MySQL storage automatically by configuring the Custom Resource manifest. Alternatively, you can scale the storage manually. For either way, the volume type must support PVCs expansion.

Check expansion capability for your volume type¶

Certain volume types support PVCs expansion by default. You can run the following command to check if your storage supports the expansion capability:

$ kubectl describe sc <storage class name> | grep AllowVolumeExpansion

Expected output

AllowVolumeExpansion: true

Find exact details about PVCs and the supported volume types in Kubernetes documentation .

Automated scaling with Volume Expansion capability¶

In this document we’re using the default Percona Server for MySQL cluster name cluster1. If you have a different name, replace cluster1 with it in the commands.

To enable automated scaling, do the following:

Set the enableVolumeExpansion Custom Resource option to true (it is turned off by default). When enabled, the Operator will automatically expand the storage for you when you define a new size in the Custom Resource

Change the mysql.volumeSpec.persistentVolumeClaim.resources.requests.storage option in the deploy/cr.yaml file to the desired storage size.

Here’s the example configuration:

spec:
  ...
  enableVolumeExpansion: true
    ...
  mysql:
    ...
    volumeSpec:
      ...
      persistentVolumeClaim:
        resources:
          requests:
            storage: <NEW STORAGE SIZE>

Apply the new configuration:
```
$ kubectl apply -f cr.yaml
```

The storage size change takes some time. When it starts, the Operator automatically adds the pvc-resize-in-progress annotation to the PerconaServerMySQL Custom Resource. The annotation contains the timestamp of the resize start and indicates that the resize operation is running.. After the resize finishes, the Operator deletes this annotation.

Manual scaling¶

To increase the storage size, do the following:

Extract and backup the cluster configuration

$ kubectl get ps cluster1 -o yaml > CR_backup.yaml

Now you should delete the cluster.

You can use the following command to delete the cluster:
```
$ kubectl delete ps cluster1
```

For each node, edit the yaml to resize the PVC object.

$ kubectl edit pvc datadir-cluster1-mysql-0

In the yaml, edit the spec.resources.requests.storage value.

spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 6Gi

Perform the same operation on the other nodes.

$ kubectl edit pvc datadir-cluster1-mysql-1
$ kubectl edit pvc datadir-cluster1-mysql-2

In the CR configuration file, use vim or another text editor to edit the PVC size.
```
$ vim CR_backup.yaml
```
Set the new storage size for the mysql.volumeSpec.persistentVolumeClaim.resources.requests.storage option:
```
mysql:
volumeSpec:
  persistentVolumeClaim:
    resources:
      requests:
        storage: 6Gi
```
The size of the storage must match the size you defined for the PVC object on the cluster nodes.
Apply the updated configuration to the cluster.
```
$ kubectl apply -f CR_backup.yaml
```

The storage size change takes some time. When it starts, the Operator automatically adds the pvc-resize-in-progress annotation to the PerconaServerMySQL Custom Resource. The annotation contains the timestamp of the resize start and indicates that the resize operation is running. After the resize finishes, the Operator deletes this annotation.

Horizontal scaling¶

Size of the cluster is controlled by a size key in the Custom Resource options configuration. That’s why scaling the cluster needs nothing more but changing this option and applying the updated configuration file. This may be done in a specifically saved config, or on the fly, using the following command:

$ kubectl patch ps cluster1 --type='json' -p='[{"op": "replace", "path": "/spec/mysql/size", "value": 5 }]'

In this example we have changed the size of the Percona Server for MySQL Cluster to 5 instances.

Last update: 2025-09-02