To orchestrate event broker services, Solace deploys the PubSub+ Mission Control Agent in a dedicated namespace. The Mission Control Agent creates a secure connection back to the PubSub+ Home Cloud and relays user commands from the console to the event broker service. This configuration is firewall friendly; all connections originate outbound.
The following diagram shows the deployment architecture for PubSub+ Cloud in Kubernetes environments.
For more details, see Resource Requirements for Kubernetes and Default Port Configuration and Connectivity Model for Kubernetes Deployments.
PubSub+ Cloud uses Availability Zones and Kubernetes StatefulSets to manage the deployment of event broker services, as shown in the following diagram:
The event broker service consists of three software event brokers, each deployed in a separate pod. Each pod also contains a Datadog agent that provides monitoring data and logs to the central monitoring service.
For details, see Central Monitoring Service and Datadog Agents.
To ensure that high-availability event broker services are properly provisioned, PubSub+ Cloud requires three Availability Zones (AZs), one for each member of the High Availability (HA) triplet (primary messaging broker, backup messaging broker, and monitoring broker). For each HA service, the Mission Control Agent deploys the primary pod in one AZ, the backup pod in a second AZ, and the monitoring pod in a third AZ. This guarantees that pods for the same HA service are not running on the same hardware.
Some regions do not have availability zones available, or you may decide that you don't require an availability zone configured for your Kubernetes cluster.
When your target cluster doesn't have Availability Zones, the Mission Control Agent still deploys the pods. In this case, it is possible for multiple pods to be affected by any outages that occur. Because of this, for those deployments without Availability Zones, we recommend that worker nodes be scheduled on separate physical machines.
When availability zones are not available, it's important to note that the IaaS has reduced fault tolerance when compared to having availability zones present. Regardless of this fact, the region operates with the best availability possible in all deployments.
On-premises deployments should pay special attention to how they organize their Availability Zones (AZ). It is important, where possible, to have the individual worker nodes of high-availability (HA) event broker services physically distanced when possible. Any physical distance helps ensure the resiliency of your HA event broker services.
You can achieve physical distance by deploying your event broker services to different data centers you own, with each data center as an AZ. Even in situations where you only have one data center, you can sub-divide that data center into different AZs. Examples of how you can create separation include creating an AZ for each:
- room in your data center
- electric circuit within your data center
- rack in your data center
- server in your data center
Using availability zones requires you label each of the worker nodes in the Kubernetes cluster with its associated availability zone. See Running in multiple zones in the Kubernetes’ documentation for information.
A StatefulSet is the Kubernetes Workload API object used to manage stateful applications.
StatefulSets manage the deployment and scaling of a set of pods, and provide guarantees about the ordering and uniqueness of these pods. PubSub+ Cloud uses three StatefulSets to manage the deployment of a HA group, one for each role (primary, backup, monitoring).
For more information about StatefulSets, see the Kubernetes documentation.
For information about the list of broker versions available in PubSub+ Cloud, see Software Event Broker Versions and Support in PubSub+ Cloud.