Kubernetes Deployments

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 Types Compared

Kubernetes workload choice for MQ
WorkloadGood forBad for
DeploymentStateless gateways, toolingSingle shared QM data directory
StatefulSetOne QM per pod with stable name and PVCHorizontally scaled identical stateless APIs
MQ OperatorEnterprise lifecycle, certs, upgradesQuick one-off laptop test without install cost

Minimal StatefulSet Pattern (Conceptual)

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.

yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
apiVersion: 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

Services and Client Connectivity

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.

Secrets, ConfigMaps, and GitOps

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.

Health Probes: Liveness and Readiness

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.

Resources and Quality of Service

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.

Explainer: Apartment Building for Programs

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.

Networking and Security

  • NetworkPolicy: allow 1414 only from application namespaces.
  • Service mesh sidecars: verify they support binary MQI traffic or exclude MQ ports.
  • TLS: mount keystores via Secret; rotate with cert-manager.
  • CONNAUTH and CHLAUTH unchanged from VM MQ—containers are not softer by default.

Observability on Kubernetes

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.

Upgrades and Rollouts

  1. Backup PVC snapshot and export config.
  2. Update image tag in manifest or Operator spec.
  3. Roll pods with surge policy that never runs two writers on one PVC.
  4. Validate dspmqver and test channels before declaring done.

When Deployments Still Appear in MQ Estates

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.

Explain Like I'm Five: Kubernetes Deployments

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.

Practice Exercises

Exercise 1

Deploy one QM with StatefulSet, connect from a client pod in another namespace using Service DNS.

Exercise 2

Break readiness probe intentionally; observe Service endpoints removed until fixed.

Exercise 3

Sketch NetworkPolicy rules for prod MQ namespace.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. One queue manager data dir needs:

  • One writer pod
  • Many random pods
  • No storage
  • ConfigMap only

2. Service port 1414 is for:

  • MQ TCP listener
  • HTTPS only
  • DNS
  • SMTP

3. LICENSE in K8s is set via:

  • Container env
  • Ingress annotation
  • PVC label
  • CronJob only

4. MQ Operator manages:

  • QueueManager CR
  • JES spool
  • Db2 buffers
  • CICS tasks
Published
Read time21 min
AuthorMainframeMaster
Verified: IBM MQ 9.4 Kubernetes documentation