Supported deployments
Use one non-clustered Docker server for development and testing, or an operator-managed Kubernetes cluster with at least three servers.
KubeMQ supports two deployment shapes.
- Docker: one non-clustered server for development and testing. Use the Docker guide. The self-service trial covers this one-server shape.
- Kubernetes: an operator-managed cluster with at least three servers. Use the Helm guide. Request a multi-server trial or license from KubeMQ before installing the cluster.
The server's single-binary architecture describes how KubeMQ is packaged. It does not make native broker processes running directly on hosts, virtual machines, or bare metal; Podman broker deployments outside Kubernetes; Docker clusters; or standalone Kubernetes installations supported.
Kubernetes uses the container runtime supplied by Kubernetes, such as containerd. The Podman restriction applies to broker deployments outside Kubernetes.
Kubernetes requirements
The KubeMQ operator must create and manage every server pod. A hand-written StatefulSet, Deployment, or Pod is rejected by the server.
Each Kubernetes cluster must have at least three servers. The operator requires
spec.replicas to be at least 3; when it is omitted or set to 0, the operator defaults it
to 3. The cluster must provide three distinct routes so servers can reach each other.
Setting standalone: true is rejected.
The self-service trial permits one server, so it cannot start a supported Kubernetes cluster. Request a multi-server trial or license from KubeMQ for Kubernetes.
Use an odd server count such as 3, 5, or 7 for quorum. For local work, use Docker instead of a one-server Kubernetes deployment.
Moving an existing installation
An unsupported installation must migrate to one of the supported shapes before upgrading. For migration steps and data boundaries, see Coming from legacy v2.
Was this page helpful?