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
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.
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.
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.
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--memoryand--cpusto 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 nodesThe 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.
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.
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 --watchBy default this method installs the Operator in the pubsubplus-operator-system namespace.
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.
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-exampleA 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-exampleThe 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-exampleThis 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-exampleFor more information about Prometheus monitoring, see Exposing Metrics to Prometheus in the detailed PubSub+ Operator documentation.
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 atlocalhost:<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
Login as user admin with the management admin password you obtained.
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.
Refer to the detailed PubSub+ Event Broker Operator documentation for:
Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.
See the list of contributors who participated in this project.
This project is licensed under the Apache License, Version 2.0. - See the LICENSE file for details.
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.