5.6 与 Docker 和 Kubernetes 集成

5.6 与 Docker 和 Kubernetes 集成

本节摘要：容器化解决两个不同的问题：Docker 一键拉起本地开发环境，Kubernetes 承载生产级有状态部署。核心难点同一个——消息队列是有状态服务，数据卷、节点身份、资源水位必须"容器重生后依然如故"。本节给出开发与生产两套可直接使用的部署方案。

工程化整理的最后一站。前面所有章节的实验环境，现在要变成可复制的声明式部署：一条命令拉起本地环境，一套清单交付生产集群。

Docker：五分钟本地环境

官方镜像带管理插件的标签是本地开发首选：

# 一条命令拉起带管理界面的本地 Broker
docker run -d --name mq-dev \
  -p 5672:5672 -p 15672:15672 \
  -e RABBITMQ_DEFAULT_USER=dev \
  -e RABBITMQ_DEFAULT_PASS=devpass \
  rabbitmq:3.13-management
# 预期输出：
# <容器 id 串>

# 验证：容器内执行状态检查
docker exec mq-dev rabbitmqctl status | head -3
# 预期输出（节选）：
# Runtime
#   Status of node rabbit@<container-id> ...
​

浏览器访问本机管理端口即可进入 4.2 节的驾驶舱。本地环境有个反直觉的最佳实践：别给开发容器挂持久卷。开发环境的价值是"随时重置回干净状态"——加上卷之后，半年前实验的幽灵队列会一直陪着你，排查问题时全是干扰。要测试持久化行为，重启容器（数据在容器层会丢）反而更接近 3.2 节的重启实验语义。

团队协作时再进一步：把镜像标签锁定在共享的开发配置文件里，所有人本地跑同一个版本——"我这里好的"这类争论，一半源于版本不一致，而这类争论在消息系统里格外昂贵，因为客户端与 Broker 的行为差异往往精确地藏在版本号里。

Kubernetes：有状态服务的部署要点

生产部署在 Kubernetes 上，用 StatefulSet 而非 Deployment——原因有三：稳定的节点名（RabbitMQ 集群节点以主机名互认，Pod 漂移换名等于集群天天重组）；稳定的存储（每个节点绑定自己的持久卷）；有序的启停（滚动更新时一个一个来，集群不闪断）。

图 16 容器化部署形态对照：本地与生产

一份可用的生产部署清单（节选关键字段，完整清单建议配合官方 chart 校准）：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mq
spec:
  serviceName: mq-headless
  replicas: 3                      # 仲裁队列三副本起步（4.3 节结论）
  podManagementPolicy: OrderedReady
  template:
    spec:
      containers:
      - name: rabbitmq
        image: rabbitmq:3.13-management
        resources:
          requests: { memory: "2Gi", cpu: "1" }
          limits:   { memory: "4Gi", cpu: "2" }
        env:
        - name: RABBITMQ_ERLANG_COOKIE    # 生产应改用 peer discovery 插件
          valueFrom:
            secretKeyRef: { name: mq-secrets, key: erlang-cookie }
        readinessProbe:
          exec: { command: ["rabbitmq-diagnostics", "ping"] }
          periodSeconds: 10
        volumeMounts:
        - { name: data, mountPath: /var/lib/rabbitmq }
  volumeClaimTemplates:
  - metadata: { name: data }
    spec:
      accessModes: ["ReadWriteOnce"]
      resources: { requests: { storage: 100Gi } }
​

结果与解读：三个细节决定成败。资源限额与内存水位的换算：4.1 节的内存高水位必须按容器 limit 重新设定（默认按节点内存算，容器里会算错），否则 OOM 杀手抢在 Broker 自保之前动手——3.2 节说过，进程被杀比主动阻塞糟糕得多。探针语义：readiness 用诊断命令而非 TCP 探测，端口开着不等于节点能服务（磁盘告警阻塞期端口照常监听）。灰度发布：滚动更新时镜像升级要一个节点一个节点验证 cluster_status，版本对齐纪律（4.3 节）在 K8s 里靠 maxUnavailable: 0 与分区更新实现。

变式一：本地多节点集群调试——三个 Docker 容器组一个三节点集群，验证仲裁队列的宕机演练（4.3 节实验在笔记本上复现）。变式二：验证持久卷的意义——删除一个 Pod，重建后集群状态与队列消息原样恢复；去掉持久卷重复实验，观察"容器重生即数据蒸发"。

平台化的边界

容器与平台解决部署，不解决设计。架构评审时最常见的混淆是："上 K8s 了所以扩容很方便"——队列积压时扩 Pod 有用（消费侧热区九），但 Broker 侧的容量问题（热区四、五）不会因为平台弹性而消失，磁盘与 IO 在物理层。平台化之后，4.4 节的监控告警依然一个不能少，只是指标采集端点从主机换成了 Pod。

⚠️ 常见坑：用 Deployment 跑 RabbitMQ 集群。Pod 重建后主机名全变，集群成员关系反复重组，表现为"服务时好时坏"的灵异现象。有状态服务用 StatefulSet，这是平台选型的铁律。

本节要点回顾

• 两种形态：开发用单容器无卷可重置，生产用 StatefulSet 加持久卷；
• StatefulSet 三理由：稳定节点名、独立存储、有序启停，缺一集群不稳；
• 资源换算：内存水位按容器限额显式设定，防 OOM 杀手越级执法；
• 探针语义：诊断命令做就绪探测，TCP 通不等于能服务；
• 平台边界：部署弹性不替代容量治理，监控告警一个不少。

平台落地完成，工程化整理收官。第 6 章用三个行业案例检验工具箱，并交出排错手册与演进展望。