Kubernetes deployments—in the everyday sense of rolling out MQ workloads on a cluster—combine images, storage, networking, and health checks into manifests Git can own. The word Deployment also names a specific workload API that runs interchangeable pods; IBM MQ queue managers rarely fit that mold because each pod needs unique persistent identity and one writer to /mnt/mqm. Beginners copy generic nginx Deployment samples, scale replicas to three, and wonder why three queue managers corrupt data or why only one pod starts. This tutorial clarifies when bare Deployments suit MQ-adjacent components, when StatefulSets or the MQ Operator own the queue manager, how Services and DNS expose listeners inside and outside the cluster, environment variables and Secrets for LICENSE and passwords, probes that avoid restart storms during recovery, resource requests and limits for CPU and memory, NetworkPolicy boundaries, and a reference layout from dev namespace to production HA without treating MQ like a stateless microservice.
| Workload | Good for | Bad for |
|---|---|---|
| Deployment | Stateless gateways, tooling | Single shared QM data directory |
| StatefulSet | One QM per pod with stable name and PVC | Horizontally scaled identical stateless APIs |
| MQ Operator | Enterprise lifecycle, certs, upgrades | Quick one-off laptop test without install cost |
Production should use the MQ Operator or your platform standard; the YAML below illustrates pieces beginners must recognize: serviceName for stable DNS, volumeClaimTemplates for per-pod PVC, env LICENSE, and probes. Adjust image tag, storage class, and resources per IBM guidance for your release.
12345678910111213141516171819202122232425262728293031323334353637apiVersion: apps/v1 kind: StatefulSet metadata: name: mq-qm1 spec: serviceName: mq-qm1 replicas: 1 selector: matchLabels: app: mq-qm1 template: metadata: labels: app: mq-qm1 spec: containers: - name: qmgr image: icr.io/ibm-messaging/mq:9.4.0.0-r1 env: - name: LICENSE value: accept - name: MQ_QMGR_NAME value: QM1 ports: - containerPort: 1414 - containerPort: 9443 volumeMounts: - name: qmdata mountPath: /mnt/mqm volumeClaimTemplates: - metadata: name: qmdata spec: accessModes: [ReadWriteOnce] resources: requests: storage: 100Gi
A headless Service (clusterIP: None) returns pod DNS records such as mq-qm1-0.mq-qm1.mq.svc.cluster.local—useful for StatefulSet pod identity. A regular ClusterIP Service load-balances to ready pods; with one replica it still gives a stable VIP inside the cluster. External clients need Route, LoadBalancer, or NodePort with TLS and firewall rules. Client channel definitions should use the Service DNS name, not pod IP, so reconnect survives pod reschedule on the same PVC. For IBM MQ on OpenShift, Routes terminate HTTPS for console and REST separately from MQI port 1414.
Store MQ_ADMIN_PASSWORD in a Secret referenced by envFrom secretKeyRef—not plain YAML in Git. ConfigMaps hold MQSC snippets, mqclient.ini fragments, or metric config. Sealed Secrets or external secret operators sync from Vault. GitOps tools (Argo CD, Flux) apply manifests; drift detection compares live cluster to repo. Coordinate with Terraform that provisions the cluster versus manifests that deploy MQ.
Readiness should fail while the queue manager is starting or recovering logs so traffic does not hit a half-ready listener. Liveness should not kill a pod during legitimate long recovery—tune initialDelaySeconds and failureThreshold. Official images document chkmqready or similar scripts; prefer those over generic TCP-only checks that pass before the command server is ready. During upgrades, watch probe-induced restart loops extending outage.
Set requests and limits for CPU and memory. Under-provisioned MQ pods swap and stall channels; over-provisioned waste cluster budget. Bursty batch puts need headroom. limits without requests inherit scheduling unpredictability. Separate nodes with taints for MQ production node pools if noisy neighbors affect latency.
Kubernetes is an apartment building. Deployments assign identical apartments to interchangeable tenants. MQ is a tenant with a heavy safe bolted to the floor—the safe is the persistent volume—so you use a StatefulSet apartment with a nameplate on the door that stays the same after maintenance.
Scrape MQ metrics ServiceMonitor for Prometheus. Ship stdout logs to cluster logging. Labels on pods (qmgr=QM1, env=prod) enrich alerts. HPA on MQ pods is rarely appropriate for single QM—scale clients or split queues instead. Use Kubernetes events and describe pod for ImagePullBackOff, FailedMount, and probe failures.
Run a Deployment for stateless REST bridges, metric exporters, or sample producers in labs. Multi-queue-manager estates use one StatefulSet or QueueManager CR per QM, not one Deployment scaled to ten. Kubernetes Deployments chapter title here means deploying MQ on Kubernetes broadly—including StatefulSets and Operators—not only the apps/v1 Deployment kind.
Kubernetes is a robot landlord that starts your MQ program in a box, hooks up the power (network), and locks your files in a drawer (volume) so when the box is replaced your messages are still there.
Deploy one QM with StatefulSet, connect from a client pod in another namespace using Service DNS.
Break readiness probe intentionally; observe Service endpoints removed until fixed.
Sketch NetworkPolicy rules for prod MQ namespace.
1. One queue manager data dir needs:
2. Service port 1414 is for:
3. LICENSE in K8s is set via:
4. MQ Operator manages: