Couchbase Cluster Vertical Scaling
Vertical scaling is a Kubernetes anti-pattern but may be employed for various reasons. This page discusses some uses and how to perform vertical scaling.
Kubernetes is designed to be horizontally scalable. If a service is running low on resources or unable to handle its workload, then it can be quickly scaled to have more instances to handle the requirements. Likewise, if it has excess resource it can be scaled down.
Vertical scaling is not as well supported by Kubernetes, but may be required for a number of reasons:
Better resource utilization by requiring fewer nodes to support your workload
Reducing the relative impact of an application’s fixed overhead
Increasing capacity to cater for more data
Reducing capacity for cost savings
Upgrading storage medium for improved performance e.g. from HDD to NVMe
Upgrading to faster CPUs and memory for improved performance
Downgrading to slower CPUs and memory for cost savings
Where possible, we recommend horizontal scaling as scaling up reduces the impact of infrastructure failure and increases cluster resiliency. The impact of balancing in or out Couchbase nodes is far less than required for vertical scaling.
For whatever reason you wish to vertically scale your existing cluster, the process will be the same.
Changing either the
couchbaseclusters.spec.servers.resources attribute to tell Kubernetes to allocate more CPU and memory on shared workload nodes, the
couchbaseclusters.spec.volumeClaimTemplates.spec.resources attribute to modify persistent storage, or modifying node selectors and tolerations to run the cluster on new nodes, will require modifying Couchbase server pods.
As pods are immutable, the operator must intelligently replace old pods with new ones as described in the upgrade concepts documentation. You should fully understand and plan for the upgrade operation when performing vertical scaling.