Book a consultation

Solace Event Broker: Form Factors, Editions and Selection

Solace Kubernetes Operator, Helm and OpenShift: Running the Broker

The Solace Kubernetes Operator and Helm charts explained: how the broker runs as a StatefulSet, HA pods, storage, OpenShift certification and pitfalls.

Vladimir Romanov

The Solace Kubernetes Operator (the Solace Event Broker Operator, pubsubplus-eventbroker-operator) deploys and manages Solace Event Broker Software on Kubernetes and OpenShift through a custom resource called PubSubPlusEventBroker. The alternative is a set of Helm charts (pubsubplus, pubsubplus-ha and pubsubplus-dev). Both produce the same thing: a StatefulSet of broker pods, either one standalone pod or a three-pod high availability group, with persistent storage and a service that routes clients to whichever pod is active (Operator quickstart; Helm quickstart). The repositories still carry the old PubSub+ name.

This page explains how the broker runs on a cluster, how to choose between the Operator and Helm, and what goes wrong. It belongs to the Solace Event Broker overview in the Solace cluster.

How the Solace Kubernetes Operator deploys a broker

A broker is a stateful workload. It holds a message spool on disk, a configuration, and an identity that clients and other brokers connect to. That is why it runs as a StatefulSet rather than a Deployment: each pod keeps its name and its volume across restarts.

HA is three pods with different jobs. With redundancy enabled, the StatefulSet creates a primary and a backup messaging node and a monitoring node. The deployment guide describes the monitor as having minimal resource requirements, used for quorum: “a minimum of 2 nodes to reach a quorum” (Helm deployment guide). This is the same three-node group described on the HA and disaster recovery page, mapped onto pods.

Only the active pod receives traffic. A readiness probe runs a script in each pod that checks which messaging node is active and labels it active=true. The Kubernetes service selects on that label. In Solace’s words, a deployment is ready “when there is a Solace pod that is running, 1/1 ready, and the pod’s label is ‘active=true.’” On failover the label moves to the backup, and clients reconnect to the same service address. The probe needs pod-to-pod communication and access to the Kubernetes API, which matters on locked-down clusters.

Each messaging pod has its own volume. The chart creates a persistent volume claim “specifying the size and the Storage Class of the requested volume”. The spool and configuration live there.

A Solace HA broker on a Kubernetes or OpenShift cluster Inside a Kubernetes or OpenShift cluster, the Operator custom resource or a Helm release creates a StatefulSet of three pods on three worker nodes. Worker node A runs the primary messaging pod, labelled active=true, with its own persistent volume claim for spool and configuration. Worker node B runs the backup messaging pod in standby, with its own volume. Worker node C runs the monitoring pod, which carries no messages and breaks ties. Primary and backup synchronise configuration and guaranteed message state over the mate link. A service of type LoadBalancer selects only the pod labelled active=true. Clients outside the cluster, using MQTT, SMF, AMQP or REST, connect through that service. Kubernetes or OpenShift cluster Operator CR or Helm release PubSubPlusEventBroker / pubsubplus-ha StatefulSet, three pods readiness probe labels the active pod Worker node A Primary pod active=true PVC: spool and config StorageClass, not NFS Worker node B Backup pod standby PVC: spool and config StorageClass, not NFS Worker node C Monitoring pod small, breaks ties carries no messages Service (LoadBalancer) selects only the pod labelled active=true Dashed: mate link syncs config and guaranteed state Clients: MQTT, SMF, AMQP, REST
Kubernetes restarts pods, but the broker decides which pod is active. The service follows a label the readiness probe sets, so clients keep one address through a failover.

Operator or Helm?

Solace Event Broker OperatorHelm charts
What you declareA PubSubPlusEventBroker custom resourceValues for pubsubplus, pubsubplus-ha or pubsubplus-dev
ModesStandalone, three-node HA, developerStandalone, HA, developer
LifecycleController handles upgrades and repairHelm upgrades you run
MonitoringPrometheus exporter optionNot covered in the quickstart
OpenShiftRed Hat certified catalog and OperatorHubSeparate OpenShift quickstart
Minimum per pod (production)2 CPUs, 4 GB memory2 CPUs, 4 GB memory
Minimum (developer)1 CPU, 4 GB memory1 CPU, 2 GB memory

Sources: the Operator and Helm quickstarts, as fetched in October 2026.

Our view: pick the tool your platform team already runs well. A team that manages databases and Kafka through operators will be comfortable with the Operator. A team whose whole estate is Helm charts in a GitOps repository will be faster with Helm. The broker behaves the same either way.

Storage and sizing

The Helm deployment guide sizes the spool volume with simple tiers that match connection scale: 5 GB for dev, 14 GB for prod1k, 18 GB for prod10k, 30 GB for prod100k and 34 GB for prod200k. These are starting points for the broker’s own needs, not for your backlog. Size the volume for the longest consumer outage you want to ride through, then add margin.

Two rules matter more than the size:

  1. No NFS in production. The guide states “NFS is currently supported for development and demo purposes” only.
  2. Use storage with predictable latency. Guaranteed messages are written to the spool before the publisher gets its acknowledgement, so slow disks slow every guaranteed publisher.

Finer limits (maxConnections, maxQueueMessages, maxSpoolUsage, Kafka bridge counts and others) can be set individually when the tiers do not fit.

OpenShift and Customer-Controlled Regions

On OpenShift, the software broker and the Operator are listed in the Red Hat certified catalog, and Solace keeps a separate OpenShift quickstart. Security context constraints and restricted API access on OpenShift are the usual friction points for the readiness probe.

There is a third option: let Solace run the brokers on your cluster. In a Customer-Controlled Region, Solace Cloud’s control plane deploys and manages brokers on your own Kubernetes (OpenShift, Rancher RKE1 and RKE2, EKS, AKS and ARO, GKE and others), while you own cluster health. The Solace Cloud page covers that split of responsibility.

Upgrades

Solace’s long-term support release 10.26.0 (June 2026) added Kubernetes readiness probes for rolling upgrades (10.26.0 notes). In an HA group the aim is to upgrade one messaging node at a time while the other carries traffic; follow Solace’s upgrade procedure for the exact order. Test that sequence with your client reconnect settings before you rely on it. Release tracks are explained on the releases and LTS page.

Should a plant run the broker on Kubernetes at all?

Only if the plant already runs Kubernetes for something else and has people who operate it. A broker is a poor first workload for a new cluster: it is stateful, latency-sensitive and everything depends on it. An illustrative comparison: a site with a two-host virtualisation cluster and a small IT team will get a more dependable broker from three VMs (primary, backup and monitor) than from a cluster built for the purpose. A company with a central platform team that already runs OpenShift at each plant for MES and analytics workloads is in the opposite position: the Operator gives it a repeatable broker per site, managed like everything else. The software vs appliance page has a decision tree that ends in exactly this question.

The network underneath

Monochrome view of a rack crowded with tangled network cables and patch panels
Kubernetes abstracts compute, not the network: plant clients still have to reach the broker's service through zones, firewalls and a load balancer someone has to own.

The service defaults to type LoadBalancer. On a managed cloud cluster that is a line of YAML. On an on-premises cluster in a plant, the Operator documentation notes there “may be no integrated Load Balancer available”, so someone has to provide one, and give it an address that MQTT gateways on the control network can reach through the industrial DMZ. That is a network design question as much as a platform one. Our guide to OT network segmentation in brownfield plants covers the zones and conduits, and an OT network assessment is where we would check them.

Where it gets hard

  • Spread the pods. Put the primary, backup and monitor on different worker nodes, and ideally different failure domains. Anti-affinity is your responsibility; a three-pod HA group on one node is not HA.
  • Tested versions lag. The Operator README, as fetched in October 2026, still names broker 10.3 as tested and recommended, and lists GKE and OpenShift 4 on AWS as tested platforms. Check the current release notes against the LTS you plan to run.
  • Probe permissions. The readiness probe needs Kubernetes API access to set the label. Restrictive RBAC or network policies break failover quietly.
  • Storage performance hides until load. A slow StorageClass looks fine in a pilot and throttles guaranteed publishers in production.
  • Client reconnect settings. Failover is only as fast as the clients’ retry and reconnect configuration.

Related: Solace Event Broker · HA and disaster recovery · Software vs Appliance · Solace hub

Frequently asked questions

What is the Solace Kubernetes Operator?

The Solace Event Broker Operator is a Kubernetes operator that deploys and manages Solace Event Broker Software through a custom resource called PubSubPlusEventBroker. It supports standalone, three-node high availability and developer deployments, handles upgrades and repair, and can enable Prometheus monitoring. It is listed on OperatorHub and in the Red Hat certified catalog.

Should I use the Solace Operator or the Helm chart?

Both deploy the same broker as a StatefulSet. The Operator suits teams that manage platforms through operators and want lifecycle actions handled by a controller, and it is the certified path on OpenShift. The Helm charts suit teams that already template everything with Helm and prefer explicit releases. Pick the one your platform team already operates well.

How does Solace high availability work on Kubernetes?

An HA deployment runs three pods: a primary and a backup messaging node and a small monitoring node that breaks ties. A readiness probe labels whichever messaging pod is active with active=true, and the Kubernetes service routes client traffic only to that pod. On failover the label moves and clients reconnect through the same service address.

Is Solace certified on Red Hat OpenShift?

Yes. The software broker and the Solace Event Broker Operator are listed as certified in the Red Hat catalog, and Solace maintains an OpenShift quickstart on GitHub. Solace Cloud's Customer-Controlled Regions also run on OpenShift, including Azure Red Hat OpenShift, among other Kubernetes distributions.

What storage does the Solace broker need on Kubernetes?

Each messaging pod uses a persistent volume claim for its message spool and configuration, provisioned through a StorageClass. Solace's Helm deployment guide states NFS is supported for development and demo purposes only. Use block storage with predictable latency for production, because guaranteed messaging writes to that volume before acknowledging the publisher.

References and further reading

  1. Solace Event Broker Operator quickstart · Solace (GitHub, SolaceProducts)The Operator, its custom resource, deployment modes and resource minimums.
  2. Solace Event Broker on Kubernetes: Helm quickstart · Solace (GitHub, SolaceProducts)
  3. Solace Event Broker Kubernetes deployment guide (Helm) · Solace (GitHub, SolaceProducts)StatefulSet design, the active=true label, storage classes and sizing tiers.
  4. Solace Event Broker Operator in the Red Hat Ecosystem Catalog · Red Hat
  5. Solace Event Broker OpenShift quickstart · Solace (GitHub, SolaceProducts)
  6. Solace Cloud deployment ownership models · Solace documentationCustomer-Controlled Regions on your own Kubernetes.

← Event Broker

Have a project that needs technical ownership?

Send us the situation. If it is not something we should take on, we will say so.

Book a consultation Contact