Scale for a PostgreSQL cluster

You can scale a PostgreSQL cluster in two ways, vertical scaling and horizontal scaling.

note

After vertical scaling or horizontal scaling is performed, KubeBlocks automatically matches the appropriate configuration template based on the new specification. This is the KubeBlocks dynamic configuration feature. This feature simplifies the process of configuring parameters, saves time and effort, and reduces performance issues caused by incorrect configuration. For detailed instructions, refer to Configuration.

Vertical scaling

You can vertically scale a cluster by changing resource requirements and limits (e.g. CPU and storage). For example, you can change the resource class from 1C2G to 2C4G by performing vertical scaling.

Before you start

Check whether the cluster status is Running. Otherwise, the following operations may fail.

kubectl get cluster mycluster -n demo
>
NAME        CLUSTER-DEFINITION   VERSION             TERMINATION-POLICY   STATUS    AGE
mycluster   postgresql           postgresql-14.8.0   Delete               Running   36m

Steps

There are two ways to apply vertical scaling.

OpsRequest

1. Apply an OpsRequest to the specified cluster. Configure the parameters according to your needs.

   kubectl apply -f - <<EOF
   apiVersion: apps.kubeblocks.io/v1alpha1
   kind: OpsRequest
   metadata:
     name: ops-vertical-scaling
     namespace: demo
   spec:
     clusterName: mycluster
     type: VerticalScaling 
     verticalScaling:
     - componentName: postgresql
       requests:
         memory: "2Gi"
         cpu: "1"
       limits:
         memory: "4Gi"
         cpu: "2"
   EOF

2. Check the operation status to validate the vertical scaling.

   kubectl get ops -n demo
   >
   NAMESPACE   NAME                   TYPE              CLUSTER     STATUS    PROGRESS   AGE
   demo        ops-vertical-scaling   VerticalScaling   mycluster   Succeed   3/3        6m

   If an error occurs, you can troubleshoot with kubectl describe ops -n demo command to view the events of this operation.

3. Check whether the corresponding resources change.

   kubectl describe cluster mycluster -n demo
   >
   ......
   Component Specs:
    Component Def Ref:  postgresql
    Enabled Logs:
      running
    DisableExporter:   true
    Name:      postgresql
    Replicas:  2
    Resources:
      Limits:
        Cpu:     2
        Memory:  4Gi
      Requests:
        Cpu:     1
        Memory:  2Gi

Edit cluster YAML file

1. Change the configuration of spec.components.resources in the YAML file.

   spec.components.resources controls the requirement and limit of resources and changing them triggers a vertical scaling.

   kubectl edit cluster mycluster -n demo
   >
   ......
   spec:
     affinity:
       podAntiAffinity: Preferred
       topologyKeys:
       - kubernetes.io/hostname
     clusterDefinitionRef: postgresql
     clusterVersionRef: postgresql-14.8.0
     componentSpecs:
     - componentDefRef: postgresql
       enabledLogs:
       - running
       disableExporter: true
       name: postgresql
       replicas: 2
       resources:
         limits:
           cpu: "2"
           memory: 4Gi
         requests:
           cpu: "1"
           memory: 2Gi

2. Check whether the corresponding resources change.

   kubectl describe cluster mycluster -n demo
   >
   ......
   Component Specs:
    Component Def Ref:  postgresql
    Enabled Logs:
      running
    DisableExporter:   true
    Name:      postgresql
    Replicas:  2
    Resources:
      Limits:
        Cpu:     2
        Memory:  4Gi
      Requests:
        Cpu:     1
        Memory:  2Gi

Horizontal scaling

Horizontal scaling changes the amount of pods. For example, you can scale out replicas from three to five.

From v0.9.0, besides replicas, KubeBlocks also supports scaling in and out instances, refer to Horizontal Scale for more details and examples.

Before you start

Check whether the cluster STATUS is Running. Otherwise, the following operations may fail.

kubectl get cluster mycluster -n demo
>
NAME        CLUSTER-DEFINITION   VERSION              TERMINATION-POLICY     STATUS    AGE
mycluster   postgresql           postgresql-12.14.0   Delete                 Running   47m

Steps

There are two ways to apply horizontal scaling.

OpsRequest

1. Apply an OpsRequest to a specified cluster. Configure the parameters according to your needs.

   The example below means adding two replicas.

   kubectl apply -f - <<EOF
   apiVersion: apps.kubeblocks.io/v1alpha1
   kind: OpsRequest
   metadata:
     name: ops-horizontal-scaling
     namespace: demo
   spec:
     clusterName: mycluster
     type: HorizontalScaling
     horizontalScaling:
     - componentName: postgresql
       scaleOut:
         replicaChanges: 2
   EOF

   If you want to scale in replicas, replace scaleOut with scaleIn.

   The example below means deleting two replicas.

   kubectl apply -f - <<EOF
   apiVersion: apps.kubeblocks.io/v1alpha1
   kind: OpsRequest
   metadata:
     name: ops-horizontal-scaling
     namespace: demo
   spec:
     clusterName: mycluster
     type: HorizontalScaling
     horizontalScaling:
     - componentName: postgresql
       scaleIn:
         replicaChanges: 2
   EOF

2. Check the operation status to identify the horizontal scaling status.

   kubectl get ops -n demo
   >
   NAMESPACE   NAME                     TYPE                CLUSTER     STATUS    PROGRESS   AGE
   demo        ops-horizontal-scaling   HorizontalScaling   mycluster   Succeed   3/3        6m

   If an error occurs, you can troubleshoot with kubectl describe ops -n demo command to view the events of this operation.

3. Check whether the corresponding resources change.

   kubectl describe cluster mycluster -n demo

Edit cluster YAML file

1. Change the configuration of spec.componentSpecs.replicas in the YAML file.

   spec.componentSpecs.replicas stands for the pod amount and changing this value triggers a horizontal scaling of a cluster.

   kubectl edit cluster mycluster -n demo
   >
   apiVersion: apps.kubeblocks.io/v1alpha1
   kind: Cluster
   metadata:
     name: mycluster
     namespace: demo
   spec:
     clusterDefinitionRef: postgresql
     clusterVersionRef: postgresql-14.8.0
     componentSpecs:
     - name: postgresql
       componentDefRef: postgresql
       replicas: 1 # Change the amount
       volumeClaimTemplates:
       - name: data
         spec:
           accessModes:
             - ReadWriteOnce
           resources:
             requests:
               storage: 1Gi
    terminationPolicy: Halt

2. Check whether the corresponding resources change.

   kubectl describe cluster mycluster -n demo

Handle the snapshot exception

If STATUS=ConditionsError occurs during the horizontal scaling process, you can find the cause from cluster.status.condition.message for troubleshooting. In the example below, a snapshot exception occurs.

Status:
  conditions: 
  - lastTransitionTime: "2024-04-25T17:40:26Z"
    message: VolumeSnapshot/mycluster-postgresql-scaling-dbqgp: Failed to set default snapshot
      class with error cannot find default snapshot class
    reason: ApplyResourcesFailed
    status: "False"
    type: ApplyResources

Reason

This exception occurs because the VolumeSnapshotClass is not configured. This exception can be fixed after configuring VolumeSnapshotClass, but the horizontal scaling cannot continue to run. It is because the wrong backup (volumesnapshot is generated by backup) and volumesnapshot generated before still exist. First delete these two wrong resources and then KubeBlocks re-generates new resources.

Steps:

1. Configure the VolumeSnapshotClass by running the command below.

   kubectl create -f - <<EOF
   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshotClass
   metadata:
     name: csi-aws-vsc
     annotations:
       snapshot.storage.kubernetes.io/is-default-class: "true"
   driver: ebs.csi.aws.com
   deletionPolicy: Delete
   EOF

2. Delete the wrong backup (volumesnapshot is generated by backup) and volumesnapshot resources.

   kubectl delete backup -l app.kubernetes.io/instance=mycluster
   
   kubectl delete volumesnapshot -l app.kubernetes.io/instance=mycluster

Result

The horizontal scaling continues after backup and volumesnapshot are deleted and the cluster restores to running status.