DOC-1288 Remove limitation on reducing core count

modules/manage/pages/kubernetes/k-scale-redpanda.adoc

@@ -4,20 +4,18 @@
 :page-categories: Management, Scaling
 :env-kubernetes: true
 
-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.
+You can scale a cluster both vertically (by increasing or decreasing the resources available to existing brokers) and horizontally (by adding or removing brokers from the cluster).
 
 == 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.
+Vertical scaling involves increasing or decreasing the amount of resources available to Redpanda brokers, referred to as scaling up or scaling down. Resources include hardware resources such as CPU cores, memory, and storage.
 
 To scale a Redpanda cluster vertically, see xref:./k-manage-resources.adoc[Manage Pod Resources in Kubernetes].
 
-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 each worker node individually.
 - 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.
 
@@ -33,7 +31,7 @@ CAUTION: Redpanda does not support Kubernetes autoscalers. Autoscalers rely on C
 
 :caution-caption: Caution
 
-While you should not rely on Kubernetes autoscalers to scale your Redpanda brokers, you can prevent infrastructure-level autoscalers like Karpenter from terminating nodes that run Redpanda Pods. For example, you can set the xref:reference:k-redpanda-helm-spec.adoc#statefulset-podtemplate-annotations[`statefulset.podTemplate.annotations`] field in the Redpanda Helm values, or the xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-podtemplate[`statefulset.podTemplate.annotations`] field in the Redpanda custom resource to include:
+Do not rely on Kubernetes autoscalers to scale your Redpanda brokers. Instead, prevent infrastructure-level autoscalers, such as Karpenter, from terminating nodes that host Redpanda Pods. For example, you can set the xref:reference:k-redpanda-helm-spec.adoc#statefulset-podtemplate-annotations[`statefulset.podTemplate.annotations`] field in the Redpanda Helm values, or the xref:reference:k-crd.adoc#k8s-api-github-com-redpanda-data-redpanda-operator-operator-api-redpanda-v1alpha2-podtemplate[`statefulset.podTemplate.annotations`] field in the Redpanda custom resource to include:
 
 [,yaml]
 ----
@@ -44,7 +42,7 @@ This annotation tells Karpenter not to disrupt the node on which the annotated P
 
 === 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.
+Scaling out involves adding more brokers to your Redpanda cluster. You may want to add more brokers to increase throughput, enhance high availability, and improve fault tolerance. Adding more brokers enables a more effective distribution of data across the cluster. This is particularly important when dealing with large datasets.
 
 To add Redpanda brokers to your cluster: