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:

    Modifying CPU and memory
    • Better resource utilization by requiring fewer nodes to support your workload

    • Reducing the relative impact of an application’s fixed overhead

    Modifying storage
    • Increasing capacity to cater for more data

    • Reducing capacity for cost savings

    • Upgrading storage medium for improved performance e.g. from HDD to NVMe

    Modifying physical hardware
    • 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 resource requests to tell Kubernetes to allocate more CPU and memory on shared workload nodes, resource requests 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.