# Scale Redpanda in Kubernetes > For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [streaming-full.txt](https://docs.redpanda.com/streaming-full.txt) --- title: Scale Redpanda in Kubernetes latest-operator-version: v26.1.4 # EOL = End-of-Life (support lifecycle status) page-is-nearing-eol: "false" page-is-past-eol: "true" page-eol-date: April 30, 2025 latest-console-tag: v3.7.3 latest-connect-version: 4.93.0 docname: kubernetes/k-scale-redpanda page-component-name: streaming page-version: "24.1" page-component-version: "24.1" page-component-title: Streaming page-relative-src-path: kubernetes/k-scale-redpanda.adoc page-edit-url: https://github.com/redpanda-data/docs/edit/v/24.1/modules/manage/pages/kubernetes/k-scale-redpanda.adoc description: Learn how to scale a Redpanda cluster vertically to increase its resources and horizontally to add or remove brokers from a cluster. page-git-created-date: "2024-01-04" page-git-modified-date: "2024-07-25" support-status: past end-of-life --- You can scale a cluster both vertically, by increasing or decreasing the resources available to existing brokers, and horizontally, by increasing or decreasing the number of brokers in the cluster. ## [](#vertical-scaling)Vertical scaling Vertical scaling involves increasing the amount of resources available to Redpanda brokers (scaling up) or decreasing the amount of resources (scaling down). Resources include the amount of hardware available to Redpanda brokers, such as CPU cores, memory, and storage. To scale a Redpanda cluster vertically, see [Manage Pod Resources in Kubernetes](https://docs.redpanda.com/streaming/24.1/manage/kubernetes/k-manage-resources/). > ❗ **IMPORTANT** > > You cannot decrease the number of CPU cores in a running cluster. If your existing worker nodes have either too many resources or not enough resources, you may need to move Redpanda brokers to new worker nodes that meet your resource requirements. This process involves: - Making sure the new worker nodes are available. - Deleting each worker node one-by-one. - Deleting the Pod’s PersistentVolumeClaim (PVC). - Ensuring that the PersistentVolume’s (PV) reclaim policy is set to `Retain` to make sure that you can roll back to the original worker node without losing data. The [Nodewatcher controller](#node-pvc) can automate this process. ## [](#horizontal-scaling)Horizontal scaling Horizontal scaling involves modifying the number of brokers in your cluster, either by adding new ones (scaling out) or removing existing ones (scaling in). In situations where the workload is variable, horizontal scaling allows for flexibility. You can scale out when demand is high and scale in when demand is low, optimizing resource usage and cost. > 📝 **NOTE** > > Redpanda does not support Kubernetes autoscalers in production. Autoscalers primarily rely on CPU and memory metrics for scaling decisions, which do not fully capture the complexities involved in scaling Redpanda clusters. Improper scaling can lead to operational challenges. Therefore, we recommend manually scaling your Redpanda clusters as described in this topic. ### [](#scale-out)Scale out Scaling out is the process of adding more brokers to your Redpanda cluster. You may want to add more brokers for increased throughput, high availability, and fault tolerance. Adding more brokers allows for better distribution of data across the cluster. This can be particularly important when dealing with large data sets. To add Redpanda brokers to your cluster: 1. Ensure that you have one additional worker node for each Redpanda broker that you want to add. Each Redpanda broker requires its own dedicated worker node so that it has access to all resources. For more details, see [Kubernetes Cluster Requirements and Recommendations](https://docs.redpanda.com/streaming/24.1/deploy/deployment-option/self-hosted/kubernetes/k-requirements/). 2. If you use local PersistentVolumes (PV), ensure that your additional worker nodes have local disks available that meet the requirements of the configured StorageClass. See [Store the Redpanda Data Directory in PersistentVolumes](https://docs.redpanda.com/streaming/24.1/manage/kubernetes/storage/k-persistent-storage/). 3. If you have external access enabled, make sure that your new node has the necessary node ports open to external clients. See [Networking and Connectivity in Kubernetes](https://docs.redpanda.com/streaming/24.1/manage/kubernetes/networking/). 4. Verify that your cluster is in a healthy state: ```bash kubectl exec redpanda-0 --namespace -- rpk cluster health ``` 5. Increase the number of replicas in the Helm values: #### Helm + Operator `redpanda-cluster.yaml` ```yaml apiVersion: cluster.redpanda.com/v1alpha1 kind: Redpanda metadata: name: redpanda spec: chartRef: {} clusterSpec: statefulset: replicas: ``` ```bash kubectl apply -f redpanda-cluster.yaml --namespace ``` #### Helm ##### --values `replicas.yaml` ```yaml statefulset: replicas: ``` ```bash helm upgrade --install redpanda redpanda/redpanda --namespace --create-namespace \ --values replicas.yaml --reuse-values ``` ##### --set ```bash helm upgrade --install redpanda redpanda/redpanda --namespace --create-namespace \ --set statefulset.replicas= ``` 6. Wait until the StatefulSet is rolled out: ```bash kubectl --namespace rollout status statefulset redpanda --watch ``` 7. Verify that your cluster is in a healthy state: ```bash kubectl exec redpanda-0 --namespace -- rpk cluster health ``` ### [](#scale-in)Scale in Scaling in is the process of removing brokers from your Redpanda cluster. You may want to remove brokers for cost reduction and resource optimization. To scale in a Redpanda cluster, you must decommission the brokers that you want to remove before updating the `statefulset.replica` setting in the Helm values. See [Decommission Brokers in Kubernetes](https://docs.redpanda.com/streaming/24.1/manage/kubernetes/k-decommission-brokers/). ## [](#node-pvc)Install the Nodewatcher controller The Nodewatcher controller manages the lifecycle of PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) for Redpanda clusters. When the controller detects that a Node resource is not available, it sets the reclaim policy of the PV to `Retain`, helping to prevent data loss. Concurrently, it orchestrates the deletion of the PVC, which allows the Redpanda broker that was previously running on the deleted worker node to be rescheduled onto new, operational nodes. 1. Install the Nodewatcher controller: ### Helm + Operator You can install the Nodewatcher controller as part of the Redpanda Operator or as a sidecar on each Pod that runs a Redpanda broker. When you install the controller as part of the Redpanda Operator, the controller monitors all Redpanda clusters running in the same namespace as the Redpanda Operator. If you want the controller to manage only a single Redpanda cluster, install it as a sidecar on each Pod that runs a Redpanda broker, using the Redpanda resource. To install the Nodewatcher controller as part of the Redpanda Operator: 1. Deploy the Redpanda Operator with the Nodewatcher controller: ```bash helm repo add redpanda https://charts.redpanda.com helm upgrade --install redpanda-controller redpanda/operator \ --namespace \ --set image.tag=v26.1.4 \ --create-namespace \ --set additionalCmdFlags={--additional-controllers="nodeWatcher"} \ --set rbac.createAdditionalControllerCRs=true ``` - `--additional-controllers="nodeWatcher"`: Enables the Nodewatcher controller. - `rbac.createAdditionalControllerCRs=true`: Creates the required RBAC rules for the Redpanda Operator to monitor the Node resources and update PVCs and PVs. 2. Deploy a Redpanda resource: `redpanda-cluster.yaml` ```yaml apiVersion: cluster.redpanda.com/v1alpha1 kind: Redpanda metadata: name: redpanda spec: chartRef: {} clusterSpec: {} ``` ```bash kubectl apply -f redpanda-cluster.yaml --namespace ``` To install the Decommission controller as a sidecar: `redpanda-cluster.yaml` ```yaml apiVersion: cluster.redpanda.com/v1alpha1 kind: Redpanda metadata: name: redpanda spec: chartRef: {} clusterSpec: statefulset: sideCars: controllers: enabled: true run: - "nodeWatcher" rbac: enabled: true ``` - `statefulset.sideCars.controllers.enabled`: Enables the controllers sidecar. - `statefulset.sideCars.controllers.run`: Enables the Nodewatcher controller. - `rbac.enabled`: Creates the required RBAC rules for the controller to monitor the Node resources and update PVCs and PVs. ### Helm #### --values `decommission-controller.yaml` ```yaml statefulset: sideCars: controllers: enabled: true run: - "nodeWatcher" rbac: enabled: true ``` - `statefulset.sideCars.controllers.enabled`: Enables the controllers sidecar. - `statefulset.sideCars.controllers.run`: Enables the Nodewatcher controller. - `rbac.enabled`: Creates the required RBAC rules for the controller to monitor the Node resources and update PVCs and PVs. #### --set ```bash helm upgrade --install redpanda redpanda/redpanda \ --namespace \ --create-namespace \ --set statefulset.sideCars.controllers.enabled=true \ --set statefulset.sideCars.controllers.run={"nodeWatcher"} \ --set rbac.enabled=true ``` - `statefulset.sideCars.controllers.enabled`: Enables the controllers sidecar. - `statefulset.sideCars.controllers.run`: Enables the Nodewatcher controller. - `rbac.enabled`: Creates the required RBAC rules for the controller to monitor the Node resources and update PVCs and PVs. 2. Test the Nodewatcher controller by deleting a Node resource: ```bash kubectl delete node ``` 3. Monitor the logs of the Nodewatcher controller: - If you’re running the Decommission controller as part of the Redpanda Operator: ```bash kubectl logs -l app.kubernetes.io/name=operator -c manager --namespace ``` - If you’re running the Decommission controller as a sidecar: ```bash kubectl logs --namespace -c redpanda-controllers ``` You should see that the controller successfully deleted the PVC of the Pod that was running on the deleted Node resource. ```bash kubectl get persistentvolumeclaim --namespace ``` 4. Verify that the reclaim policy of the PV is set to `Retain` to allow you to recover the node, if necessary: ```bash kubectl get persistentvolume --namespace ```