201 lines
6.8 KiB
Markdown
201 lines
6.8 KiB
Markdown
---
|
||
tags:
|
||
- MQ
|
||
- Kubernetes
|
||
- 容器化
|
||
- 运维
|
||
create time: 2026-05-24 19:52
|
||
---
|
||
|
||
# MQ 容器化与 K8s 部署
|
||
|
||
## 概述
|
||
|
||
将消息队列部署到 Kubernetes 上，是有状态服务容器化的核心挑战之一。本文从持久存储、网络标识、有序部署三个维度分析难点，介绍 StatefulSet、Operator 模式、Helm Chart 等主流方案，并以 Strimzi Kafka Operator 为例展示生产级部署实践。
|
||
|
||
## 正文
|
||
|
||
### 为什么 MQ 上 K8s 是个难题
|
||
|
||
Kubernetes 天生为无状态服务设计——Pod 可以随时被杀掉重建、IP 随时变化、多个副本之间没有区别。但 MQ 作为有状态服务，恰恰对这三点都很敏感：
|
||
|
||
- **持久存储**：消息必须落盘，Pod 重建后数据不能丢
|
||
- **网络标识**：Broker 之间需要通过固定地址互相发现（如 Kafka 的 `broker.id` 对应固定端点）
|
||
- **有序部署**：集群启动/扩容时需要按顺序进行，不能所有 Pod 同时拉起
|
||
|
||
> [!question]
|
||
> 想象一下 Kafka 的 3 个 Broker 同时启动并互相注册，会发生什么？为什么有序启动很重要？
|
||
|
||
### StatefulSet：有状态应用的基石
|
||
|
||
StatefulSet 是 K8s 专门为有状态服务设计的控制器，解决了 Deployment 的两个核心问题：
|
||
|
||
1. **稳定的网络标识**：每个 Pod 拥有固定名称（`kafka-0`、`kafka-1`、`kafka-2`），配合 Headless Service 可以通过 DNS 直接访问
|
||
2. **稳定的持久存储**：每个 Pod 绑定独立的 PVC（PersistentVolumeClaim），Pod 重建后自动挂载原来的卷
|
||
|
||
```yaml
|
||
# StatefulSet 核心配置片段
|
||
apiVersion: apps/v1
|
||
kind: StatefulSet
|
||
metadata:
|
||
name: kafka
|
||
spec:
|
||
serviceName: kafka-headless # 关联 Headless Service
|
||
replicas: 3
|
||
template:
|
||
spec:
|
||
containers:
|
||
- name: kafka
|
||
volumeMounts:
|
||
- name: data
|
||
mountPath: /var/lib/kafka/data
|
||
volumeClaimTemplates: # 每个 Pod 自动创建独立 PVC
|
||
- metadata:
|
||
name: data
|
||
spec:
|
||
accessModes: ["ReadWriteOnce"]
|
||
storageClassName: fast-ssd
|
||
resources:
|
||
requests:
|
||
storage: 100Gi
|
||
```
|
||
|
||
但 StatefulSet 只解决了基础设施层面的问题。**什么时候该扩容、扩容后 Partition 怎么重分配、配置变更怎么滚动生效**——这些业务运维知识它一概不管。于是 Operator 登场了。
|
||
|
||
### Operator 模式：把运维知识编码
|
||
|
||
Operator = Custom Resource Definition（CRD）+ Custom Controller。核心思想是：**将人类运维专家的知识编码为程序**，让 K8s 自动执行运维操作。
|
||
|
||
对于 MQ 来说，Operator 能做到：
|
||
- 一键部署完整集群（含 ZooKeeper/KRaft）
|
||
- 滚动升级 Broker 版本（保证零停机）
|
||
- 自动处理 Partition 重分配
|
||
- 证书自动签发和轮转
|
||
|
||
主流 MQ Operator：
|
||
|
||
| MQ | Operator | 维护方 |
|
||
|----|----------|--------|
|
||
| Kafka | Strimzi | CNCF |
|
||
| RocketMQ | rocketmq-operator | Apache |
|
||
| RabbitMQ | cluster-operator | VMware |
|
||
| Pulsar | pulsar-helm-chart | Apache |
|
||
|
||
### Strimzi Kafka Operator 实战
|
||
|
||
Strimzi 是 CNCF 孵化项目，通过 CRD 将 Kafka 集群声明式管理。核心 CRD 有三个：
|
||
|
||
- **Kafka**：定义 Kafka 集群拓扑（Broker 数量、存储、配置）
|
||
- **KafkaTopic**：声明式管理 Topic
|
||
- **KafkaUser**：声明式管理用户和 ACL 权限
|
||
|
||
```yaml
|
||
# Strimzi Kafka CR 示例：3 节点集群
|
||
apiVersion: kafka.strimzi.io/v1beta2
|
||
kind: Kafka
|
||
metadata:
|
||
name: my-cluster
|
||
spec:
|
||
kafka:
|
||
version: 3.7.0
|
||
replicas: 3
|
||
listeners:
|
||
- name: plain
|
||
port: 9092
|
||
type: internal
|
||
tls: false
|
||
- name: tls
|
||
port: 9093
|
||
type: internal
|
||
tls: true
|
||
config:
|
||
offsets.topic.replication.factor: 3
|
||
transaction.state.log.replication.factor: 3
|
||
transaction.state.log.min.isr: 2
|
||
default.replication.factor: 3
|
||
min.insync.replicas: 2
|
||
storage:
|
||
type: jbod
|
||
volumes:
|
||
- id: 0
|
||
type: persistent-claim
|
||
size: 100Gi
|
||
class: fast-ssd
|
||
zookeeper:
|
||
replicas: 3
|
||
storage:
|
||
type: persistent-claim
|
||
size: 20Gi
|
||
```
|
||
|
||
Kafka 集群的完整部署架构如下：
|
||
|
||
```mermaid
|
||
graph TB
|
||
subgraph K8s["Kubernetes Cluster"]
|
||
subgraph NS["namespace: kafka"]
|
||
Operator["Strimzi Operator"]
|
||
CR["Kafka CR"]
|
||
Operator -->|"watch & reconcile"| CR
|
||
CR -->|"create"| STS["StatefulSet"]
|
||
STS -->|"manage"| Pod0["kafka-0"]
|
||
STS -->|"manage"| Pod1["kafka-1"]
|
||
STS -->|"manage"| Pod2["kafka-2"]
|
||
Pod0 ---|"PVC"| PV0["PV-0 100Gi SSD"]
|
||
Pod1 ---|"PVC"| PV1["PV-1 100Gi SSD"]
|
||
Pod2 ---|"PVC"| PV2["PV-2 100Gi SSD"]
|
||
HS["Headless Service"] -->|"DNS: kafka-0.kafka-headless"| Pod0
|
||
HS -->|"DNS: kafka-1.kafka-headless"| Pod1
|
||
HS -->|"DNS: kafka-2.kafka-headless"| Pod2
|
||
LB["LoadBalancer Service"] -->|"external access"| Pod0
|
||
LB --> Pod1
|
||
LB --> Pod2
|
||
end
|
||
end
|
||
Client["Client App"] -->|"produce/consume"| LB
|
||
```
|
||
|
||
### Helm Chart 部署
|
||
|
||
对于不想引入 Operator 的轻量场景，Helm Chart 是更简单的选择。Bitnami 提供了完善的 Kafka Helm Chart，核心优势是参数化配置和环境隔离：
|
||
|
||
```bash
|
||
# 安装 Kafka 集群
|
||
helm install my-kafka bitnami/kafka \
|
||
--namespace kafka --create-namespace \
|
||
--set replicaCount=3 \
|
||
--set persistence.size=100Gi \
|
||
--set persistence.storageClass=fast-ssd \
|
||
--set resources.requests.memory=4Gi \
|
||
--set resources.requests.cpu=2 \
|
||
--set resources.limits.memory=6Gi \
|
||
--set resources.limits.cpu=4
|
||
```
|
||
|
||
Helm 适合快速搭建和开发/测试环境，但在生产环境中，Operator 的自动化运维能力（升级、扩容、故障恢复）是 Helm 无法替代的。
|
||
|
||
### 资源规划建议
|
||
|
||
MQ 在 K8s 上的资源规划需要特别注意：
|
||
|
||
- **CPU/Memory**：Kafka Broker 建议至少 2C4G，生产环境推荐 4C8G。请求值和限制值都要设置，避免被驱逐或抢占资源
|
||
- **存储**：SSD 用于高吞吐场景（低延迟随机读写），HDD 用于大容量归档。通过 StorageClass 区分
|
||
- **JVM 堆**：Kafka Broker 堆不宜过大（4-6GB 足够），留更多内存给页缓存。推荐 G1GC 或 ZGC
|
||
- **磁盘调度**：容器内使用 `none`（noop）调度算法，避免与宿主机调度冲突
|
||
|
||
### 网络方案
|
||
|
||
| 方式 | 适用场景 | 特点 |
|
||
|------|----------|------|
|
||
| Headless Service | Broker 间内部通信 | Pod 直连，无负载均衡 |
|
||
| ClusterIP | 集群内客户端访问 | 默认方式 |
|
||
| NodePort | 开发测试外部访问 | 端口范围 30000-32767 |
|
||
| LoadBalancer | 生产外部访问 | 云厂商 LB，费用较高 |
|
||
| Ingress | HTTP 协议暴露 | MQ 一般不走 HTTP，适用 REST Proxy |
|
||
|
||
## 关联笔记
|
||
|
||
- [[40-MQ-性能调优]]
|
||
- [[42-MQ-认证与授权]]
|
||
- [[43-MQ-加密与审计]]
|