Kubernetes (Helm)

On Kubernetes, KubeMQ runs through the operator. You describe the server with a KubemqCluster custom resource, the operator reconciles it into a StatefulSet, Services, and configuration, and the Helm charts render that resource from your values.yaml. Because the chart writes values straight into the CR, a Helm value path equals the KubemqCluster spec.* path with the leading spec. removed (spec.grpc.port → grpc.port).

This guide is the single source of truth for complete, runnable Helm and CRD configurations. The Configuration overview and the reference pages show minimal single-setting snippets and link here.

Configure with values.yaml

For anything beyond the license key, supply a values.yaml file. Each value maps 1:1 to a KubemqCluster spec.* field — the chart renders your values verbatim into the CR spec, so there is no separate Helm schema to learn. A complete values.yaml:

# Replace with your license key
key: YOUR_LICENSE_KEY

# High availability: 3 replicas (set standalone: true for a single node)
replicas: 3
standalone: false

# Persistent store
volume:
  size: 20Gi
  storageClass: fast-ssd

# Interfaces — .port moves the listener + Service port together
grpc:
  port: 50000
  expose: LoadBalancer

# REST is on by default; MCP / A2A / CloudEvents ride the REST HTTP port
# (disabled: false is the default — shown here only to be explicit)
rest:
  disabled: false
  port: 9090
  expose: ClusterIP

api:
  port: 8080
  expose: LoadBalancer

# Store limits and retention — enforced on the `legacy` engine only (see callout below)
store:
  messagesRetentionMinutes: 1440
  maxChannels: 0

# Pod resources
resources:
  requestsCpu: "2"
  requestsMemory: 4Gi
  limitsCpu: "4"
  limitsMemory: 8Gi

Install (or upgrade) the cluster with the file:

helm install --wait -n kubemq kubemq-cluster kubemq-charts/kubemq-cluster -f values.yaml

The same configuration as a KubemqCluster CR — apply it directly with kubectl apply -f if you manage the resource yourself rather than through Helm:

apiVersion: core.k8s.kubemq.io/v1beta1
kind: KubemqCluster
metadata:
  name: kubemq-cluster
  namespace: kubemq
spec:
  key: YOUR_LICENSE_KEY
  replicas: 3
  standalone: false
  volume:
    size: 20Gi
    storageClass: fast-ssd
  grpc:
    port: 50000
    expose: LoadBalancer
  rest:
    disabled: false
    port: 9090
    expose: ClusterIP
  api:
    port: 8080
    expose: LoadBalancer
  store:
    messagesRetentionMinutes: 1440
    maxChannels: 0
  resources:
    requestsCpu: "2"
    requestsMemory: 4Gi
    limitsCpu: "4"
    limitsMemory: 8Gi

Single-node vs HA

The same chart runs both topologies — the difference is replicas.

key: YOUR_LICENSE_KEY
replicas: 1
standalone: true

key: YOUR_LICENSE_KEY
replicas: 3
standalone: false

A single replica (or standalone: true) runs one non-clustered node — the equivalent of one Docker container. Three or more replicas give you high availability; the operator wires up clustering across the pods. For the full deployment and HA reference, see Deployment & HA.

Expose interfaces

Each interface (grpc, rest, api) is fronted by its own Kubernetes Service. Control the Service type with expose and the published node port with nodePort:

grpc:
  expose: LoadBalancer    # ClusterIP | NodePort | LoadBalancer
api:
  expose: NodePort
  nodePort: 32080         # only used with NodePort

• ClusterIP — reachable only inside the cluster (the default for internal-only interfaces).
• NodePort — published on every node at nodePort; useful for direct access without a cloud load balancer.
• LoadBalancer — provisions an external load balancer (cloud environments).

nodePort applies only when expose: NodePort. On Docker there is no Service — publish ports with -p instead (see the Docker guide).

Zero-config Kafka

On a fresh cluster, enabling the Kafka connector is the whole story — no separate engine setting to manage:

key: YOUR_LICENSE_KEY
replicas: 3
standalone: false

kafka:
  enabled: true

With the store empty and store.engine left unset, the operator auto-selects the next persistence engine at first boot — see Storage Engines → Zero-config engine selection for the full selection rules.

External reachability needs spec.kafka.expose plus an advertised host/port pair — see Connectors → Kafka for the full listener/TLS/SAN details.

Configure by domain

Every server setting — with its type, default, valid values, and both per-target columns — lives in the domain reference pages.

Verify

Confirm the operator has reconciled the cluster and the pods are ready.

Check the KubemqCluster resource and its status:

kubectl get kubemqcluster -n kubemq

Inspect the full status, including the reconcile phase and any conditions:

kubectl describe kubemqcluster kubemq-cluster -n kubemq

Confirm the server pods are running:

kubectl get pods -n kubemq

To reach the dashboard, port-forward the API service and open http://localhost:8080:

kubectl port-forward -n kubemq svc/kubemq-cluster 8080:8080

Related

• Configuration overview — the two targets and the config model.
• Docker (single-node) — the local / dev target.
• Deployment & HA reference — packaging, replicas, and exposure in full.
• Install with Helm — the step-by-step install guide.