Scaling Connectware Components Horizontally

Adjust replica counts for Connectware components to handle higher load and improve availability.

Horizontal scaling runs multiple replicas of a Connectware component in parallel to share load and provide redundancy if a single replica fails. Scale a component when you need to handle higher throughput or improve availability beyond what the default deployment provides.

The default replica counts cover most production deployments. The sections below describe which components support scaling and how to change their replica counts.

Scalable Components

The following Connectware components support horizontal scaling:

Component	values.yaml key	Default replicas
auth-server	authServer.replicas	2
resource-status-tracking	resourceStatusTracking.replicas	2
topic-explorer	topicExplorer.replicas	2
broker	broker.replicas	3
NATS	nats.replicas	3

NATS has strict scaling constraints. Review Scaling the NATS Cluster before changing nats.replicas.

Scaling auth-server, resource-status-tracking, and topic-explorer

The auth-server, resource-status-tracking, and topic-explorer components are stateless and can be scaled independently. Set the replicas value for each component in your values.yaml:

values.yaml

authServer:
  replicas: ${REPLICAS}
resourceStatusTracking:
  replicas: ${REPLICAS}
topicExplorer:
  replicas: ${REPLICAS}

Replace ${REPLICAS} with the desired number of replicas. You do not need to set all three at once — components can be scaled independently.

After editing your values.yaml, apply the changes by running the helm upgrade command. For details, see Applying Helm Configuration Changes.

Scaling the NATS Cluster

NATS replica count is fixed after installation

The number of NATS replicas is set at initial installation and cannot be changed afterward. Scaling NATS to a different replica count after the cluster is formed and running corrupts the NATS cluster.

The only permitted operations after installation are scaling to zero (stop all pods) and scaling back to the exact original replica count (restart). Use kubectl scale for these operations. Do not change nats.replicas in your values.yaml and run helm upgrade to scale at runtime.

NATS requires an odd number of replicas. The recommended values are:

• 1 — no redundancy. Suitable for test setups only.

• 3 — n+1 redundancy. The default and recommended for most production deployments.

• 5 — n+2 redundancy. Use when you need the cluster to remain operational with two nodes unavailable at the same time.

Going beyond 5 rarely improves performance. If you need more capacity, allocate larger pods rather than more replicas.

If you need a different replica count, set nats.replicas in your values.yaml before the initial installation:

values.yaml

nats:
  replicas: 5

Stopping and Restarting the NATS Cluster

1. Check how many replicas are currently running:

kubectl get sts nats -n ${NAMESPACE}

Example output

NAME     READY   AGE
nats     3/3     6m52s

1. To temporarily stop all NATS pods, scale the StatefulSet to zero:

kubectl scale sts nats -n ${NAMESPACE} --replicas 0

1. To restart NATS, scale back to the exact original replica count:

kubectl scale sts nats -n ${NAMESPACE} --replicas ${ORIGINAL_REPLICA_COUNT}

Replace ${NAMESPACE} with your Connectware namespace and ${ORIGINAL_REPLICA_COUNT} with the replica count set during installation. Using a different value corrupts the cluster.

1. Verify that all NATS pods are running and ready before resuming normal operations:

kubectl get pods -n ${NAMESPACE} -l app.kubernetes.io/name=nats

Scaling the Broker Cluster

Scale the broker cluster up or down to change the number of broker replicas in your Kubernetes deployment. Scaling up adds more broker nodes to the cluster. Scaling down reduces the number of broker nodes.

Scaling the Broker Up or Down

1. Check how many replicas are currently set for the broker StatefulSet:

kubectl get sts broker -n ${NAMESPACE}

Example output

NAME     READY   AGE
broker   3/3     6m52s

1. Scale the StatefulSet to the desired number of replicas.

• To scale up, increase the replica count. For example, to scale up from 3 to 4 replicas:

kubectl scale sts broker -n ${NAMESPACE} --replicas 4

• To scale down, decrease the replica count. For example, to scale down from 3 to 2 replicas:

kubectl scale sts broker -n ${NAMESPACE} --replicas 2

1. Verify that all broker nodes have formed a healthy cluster:

kubectl get pods -l app.kubernetes.io/name=broker -n ${NAMESPACE} -o name | xargs -I % kubectl exec -n ${NAMESPACE} % -- vmq-admin cluster show

Example output

+--------------------------------------------------------------------+---------+
| Node                                                               | Running |
+--------------------------------------------------------------------+---------+
| [e-mail] | true    |
+--------------------------------------------------------------------+---------+
| [e-mail] | true    |
+--------------------------------------------------------------------+---------+
| [e-mail] | true    |
+--------------------------------------------------------------------+---------+

Scaling the Broker Down to Zero

1. Check how many replicas are currently set for the broker StatefulSet:

kubectl get sts broker -n ${NAMESPACE}

Example output

NAME     READY   AGE
broker   3/3     6m52s

1. Scale the StatefulSet to zero to remove all broker pods:

kubectl scale sts broker -n ${NAMESPACE} --replicas 0

1. Verify that all broker pods have been terminated:

kubectl get pods -n ${NAMESPACE} -l app.kubernetes.io/name=broker

1. Optional: To bring the broker back up, follow Scaling the Broker Up or Down and scale to your desired replica count.