Deploying PubSub+ Cloud with Kubernetes

PubSub+ Cloud supports the following Kubernetes environments:

  • On premises:
  • In the cloud:
    • Amazon Elastic Kubernetes Service (EKS)
    • Azure Kubernetes Service (AKS)
    • Azure Red Hat OpenShift (ARO)
    • Google Kubernetes Engine (GKE)
    • Alibaba Cloud Container Service for Kubernetes (ACK)
    • Huawei Cloud Container Engine (CCE)

For the list of Kubernetes versions supported for PubSub+ Cloud, see Supported Kubernetes Versions and Event Broker Service Compatibility.

Kubernetes Deployment Architecture

PubSub+ Cloud can be installed in a customer's on-premises or cloud-based Kubernetes cluster.

To orchestrate event broker services, Solace deploys the Solace Mission Control Agent in a dedicated namespace. The Mission Control Agent creates a secure connection back to the Solace 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 a simplified representation of the deployment architecture for PubSub+ Cloud in Kubernetes environments.

For more details, see Resource Requirements for Kubernetes and Kubernetes Connectivity Model.

Kubernetes Cluster Details

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 Centralized Monitoring Service and Datadog Agents.

Supported Kubernetes Versions and Event Broker Service Compatibility

Since customers manage the Kubernetes environment, it's important to understand the Kubernetes version and its compatibility with the software event broker versions that are used in PubSub+ Cloud. Depending on the version of the Kubernetes, a minimum version of the event broker service is required.

If you are upgrading your Kubernetes cluster, we recommend that you first upgrade your event broker services to ensure compatibility and prevent downtime. For information about upgrading your event broker services, see Software Event Broker Versions and Support in PubSub+ Cloud.

In general, all versions of event broker service are supported on all versions of cloud and on-premises deployments of Kubernetes. The following table shows:

  • A minimum version of the software event broker version where required; a check mark indicates no minimum software event broker version is required.
  • For all cloud and on-premises deployments of Kubernetes, depending on the Kubernetes version, sometimes a minimum software event broker version is required.
All Cloud and On-Premises
Deployments of Kubernetes Versions (Corresponding OpenShift version)
Software Event Broker Version in PubSub+ Cloud
9.13 9.12 9.11 9.10 9.9 9.8.1 9.6

1.21

( includes RedHat OpenShift 4.8)

Only software event broker versions 9.10.0.12 and later Only software event broker versions 9.9.0.28 and later Only software event broker versions 9.8.1.33 and later

Only software event brokerr versions 9.6.0.50 and later

1.20

( includes RedHat OpenShift 4.7)

Only software event broker versions 9.6.0.34 and later

1.19

(includes RedHat OpenShift 4.6)

Only broker versions 9.6.0.34 and later

For information about the list of broker versions available in PubSub+ Cloud, see Software Event Broker Versions and Support in PubSub+ Cloud.

Availability Zones

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.

No Availability Zones

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.

StatefulSets

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.