Solace PubSub+ Event Broker Operator Quick Start

The Solace PubSub+ Event Broker Operator (or simply the Operator) is a Kubernetes-native method to install and manage a Solace PubSub+ Software Event Broker on a Kubernetes cluster.

PubSub+ Platform is a complete event streaming and management platform for the real-time enterprise. The PubSub+ Software Event Broker efficiently streams event-driven information between applications, IoT devices, and user interfaces running in the cloud, on-premises, and in hybrid environments using open APIs and protocols like AMQP, JMS, MQTT, REST and WebSocket. It can be installed into a variety of public and private clouds, PaaS, and on-premises environments. Event brokers in multiple locations can be linked together in an Event Mesh to dynamically share events across the distributed enterprise.

Contents:

Solace PubSub+ Event Broker Operator Quick Start

Overview

This document provides a quick getting started guide to install a software event broker in various configurations onto a Kubernetes cluster using the PubSub+ Event Broker Operator. Note that a Helm-based deployment of the broker is also supported but out of scope for this document.

These instructions apply to any platform supporting Kubernetes, and include specific hints for setting up a simple MiniKube or Kind deployment on a Linux-based machine.

The following Kubernetes platforms have been tested:

Google Kubernetes Engine (GKE)
OpenShift 4 Platform on AWS

The tested and recommended PubSub+ Software Event Broker version is 10.3.

Additional Documentation

Detailed documentation is provided in the Solace PubSub+ Event Broker Operator User Guide. In particular, consult the Deployment Planning section of the User Guide when planning your deployment.

How to deploy the PubSub+ Software Event Broker onto Kubernetes using the Operator

The PubSub+ Software Event Broker can be deployed in either a three-node High-Availability (HA) group or as a single-node standalone deployment. For a simple test environment used only for validating application functionality, a standalone deployment is sufficient. Note that in production, or any environment where message loss cannot be tolerated, an HA deployment is required.

In this quick start we go through the steps to deploy a PubSub+ Software Event Broker using the PubSub+ Event Broker Operator.

1. Get a Kubernetes environment

Follow your Kubernetes provider's instructions (additional options available here). Ensure you meet minimum CPU, Memory, and Storage requirements for the targeted PubSub+ Software Event Broker configuration size.

Important: The broker resource requirements refer to available resources on a Kubernetes node.

Note: If you're using MiniKube, use minikube start, specifying the options --memory and --cpus to assign adequate resources to the MiniKube VM. The recommended memory is 1GB plus the minimum requirements of your event broker.

You must also have the kubectl tool installed locally.

To verify that your Kubernetes environment is ready, run the following command:

# This command returns the list of worker nodes and their status
kubectl get nodes

2. Install the Operator

The Operator is available from the Registry for Kubernetes Operators, OperatorHub.io. With OperatorHub, the operator lifecycle, including installation and upgrades, is managed by the Operator Lifecycle Manager (OLM). Depending on your Kubernetes distribution, the OLM may already be pre-installed. If it is not, you must add it before you install the Operator.

Although the OLM is the recommended way to install the PubSub+ Event Broker Operator because of the lifecycle services it provides, a simpler, direct install method is also available that doesn't require OLM.

After you complete any of the following install options with the default settings, the Event Broker Operator will be up and running, watching all namespaces for PubSubPlusEventBroker Custom Resources, and ready for the next steps.

Note: Ensure there is only one installation of the Operator at any time to avoid conflicts.

a) OperatorHub and OLM Option

Follow the steps from OperatorHub to first setup OLM, then to install the PubSub+ Event Broker Operator. Click on the Install button to see the detailed instructions.

By default this method installs the Operator in the operators namespace.

b) Direct Option

The following commands directly install the Operator:

# Download manifest for possible edit
wget https://raw.githubusercontent.com/SolaceProducts/pubsubplus-kubernetes-quickstart/main/deploy/deploy.yaml
# Manifest creates a namespace and all K8s resources for the Operator deployment
kubectl apply -f deploy.yaml
# Wait for deployment to complete
kubectl get pods -n pubsubplus-operator-system --watch

By default this method installs the Operator in the pubsubplus-operator-system namespace.

3. PubSub+ Software Event Broker Deployment Examples

The section includes examples for the following deployment variants, with default small-scale configurations:

a) Example Minimum-footprint Deployment for Developers—Recommended minimal standalone PubSub+ Software Event Broker for Developers. No guaranteed performance
b) Example non-HA Deployment—Standalone, production-ready PubSub+ Software Event Broker with performance supporting up to 100 client connections
c) Example HA Deployment—PubSub+ Software Event Broker with brokers in HA redundancy group, production-ready performance supporting up to 100 client connections
d) Deployment with Prometheus Monitoring Enabled—an example non-HA deployment with Prometheus monitoring enabled

By default the latest publicly available Docker image of the PubSub+ Software Event Broker Standard Edition is used.

For other PubSub+ Software Event Broker configurations, refer to the PubSub+ Event Broker Operator Parameters Reference and the User Guide.

Important: Although the non-HA and HA deployments have performance that is suitable for Production, we recommend that you consult the Security Considerations documentation for information about adequate security hardening in your environment.

a) Example Minimum-footprint Deployment for Developers

This minimal non-HA deployment requires 1 CPU and 4 GB of memory available to the event broker pod.

# Create deployment manifest
echo "
apiVersion: pubsubplus.solace.com/v1beta1
kind: PubSubPlusEventBroker
metadata:
  name: dev-example
spec:
  developer: true" > developer.yaml
# Then apply it
kubectl apply -f developer.yaml
# Wait for broker deployment pods to be ready
kubectl get pods --show-labels --watch
# Check service-ready
kubectl wait --for=condition=ServiceReady eventbroker dev-example

b) Example non-HA Deployment

A minimum of 2 CPUs and 4 GB of memory must be available to the event broker pod.

# Create deployment manifest
echo "
apiVersion: pubsubplus.solace.com/v1beta1
kind: PubSubPlusEventBroker
metadata:
  name: non-ha-example
spec:
  redundancy: false  # Default, not strictly required
" > nonha.yaml
# Then apply it
kubectl apply -f nonha.yaml
# Wait for broker deployment pods to be ready
kubectl get pods --show-labels --watch
# Check service-ready
kubectl wait --for=condition=ServiceReady eventbroker non-ha-example

c) Example HA Deployment

The minimum resource requirements are 2 CPUs and 4 GB of memory available to each of the three event broker pods.

# Create deployment manifest
echo "
apiVersion: pubsubplus.solace.com/v1beta1
kind: PubSubPlusEventBroker
metadata:
  name: ha-example
spec:
  redundancy: true
" > ha.yaml
# Then apply it
kubectl apply -f ha.yaml
# Wait for broker deployment pods to be ready
kubectl get pods --show-labels --watch
# Check service-ready and then HA-ready
kubectl wait --for=condition=ServiceReady eventbroker ha-example
kubectl wait --for=condition=HAReady eventbroker ha-example

d) Deployment with Prometheus Monitoring Enabled

This is the same as the non-HA deployment example with Prometheus monitoring enabled.

# Create deployment manifest
echo "
apiVersion: pubsubplus.solace.com/v1beta1
kind: PubSubPlusEventBroker
metadata:
  name: non-ha-monitoring-enabled-example
spec:
  monitoring:
    enabled: true
" > nonha-with-monitoring.yaml
# Then apply it
kubectl apply -f nonha-with-monitoring.yaml
# Wait for broker deployment pods to be ready plus monitoring pod running
kubectl get pods --show-labels --watch
# Check service-ready and then HA-ready
kubectl wait --for=condition=ServiceReady eventbroker non-ha-monitoring-enabled-example
kubectl wait --for=condition=MonitoringReady eventbroker non-ha-monitoring-enabled-example

For more information about Prometheus monitoring, see Exposing Metrics to Prometheus in the detailed PubSub+ Operator documentation.

Solace Pubsub+ Prometheus Exporter End of Life Notice : Please note that Solace will end of life Pubsub+ Prometheus Exporter version 1.0.1 as of June ,2024. This means there will be no releases for Pubsub+ Prometheus Exporter after June ,2024, however, Solace will continue to provide technical support for it until June, 2025. Refer https://solace.com/legal/technical-product-support/ for support terminologies. If you have monitoring enabled, the operator will default to downloading the Solace version of Pubsub+ Prometheus Exporter 1.0.1. The community version of the Prometheus Exporter available at https://github.com/solacecommunity/solace-prometheus-exporter can be deployed with Pubsub+ Event Broker Operator. Note that Solace does not officially support the community version of the Prometheus Exporter.

4. Test the deployment

The examples in the preceding section create a deployment. You can use the commands that follow to check the event broker deployment status, get information about the service name and type to access the broker services, and the obtain the secret that contains the credentials to be used for admin access.

The following examples use dev-example as the deployment name. When you run these commands, use your deployment's name instead.

kubectl describe eventbroker dev-example

Obtain the management admin password:

ADMIN_SECRET_NAME=$(kubectl get eventbroker dev-example -o jsonpath='{.status.broker.adminCredentialsSecret}')
# This command returns the management "admin" user's password
kubectl get secret $ADMIN_SECRET_NAME -o jsonpath='{.data.username_admin_password}' | base64 -d

Obtain the IP address to access the broker services:

BROKER_SERVICE_NAME=$(kubectl get eventbroker dev-example -o jsonpath='{.status.broker.serviceName}')
# This command returns the broker service's external IP address
kubectl get svc $BROKER_SERVICE_NAME -o jsonpath='{.status.loadBalancer.ingress}'

Note: When using MiniKube or other minimal Kubernetes provider, there may be no integrated Load Balancer available, which is the default service type. For a workaround, either refer to the MiniKube documentation for LoadBalancer access or use local port forwarding to the service port: kubectl port-forward service/$BROKER_SERVICE_NAME <target-port-on-localhost>:<service-port-on-load-balancer> &. Then access the service at localhost:<target-port-on-localhost>

Access the PubSub+ Broker Manager

In your browser, navigate to the IP address you obtained, using port 8080:

http://<ip-address>:8080

If required use above Load Balancer access workaround for service port 8080.

Use the Broker Manager built-in Try-Me tool to test messaging.

If required use above Load Balancer access workaround for service port 8008.

Additional information

Refer to the detailed PubSub+ Event Broker Operator documentation for:

Contributing

Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.

Authors

See the list of contributors who participated in this project.

License

This project is licensed under the Apache License, Version 2.0. - See the LICENSE file for details.

Resources

For more information about Solace technology in general please visit these resources:

The Solace Developer Portal website at: solace.dev
Understanding Solace technology
Ask the Solace community.

SolaceProducts / pubsubplus-kubernetes-quickstart

readme