EKS 上的 Kafka 深入解析
概述
本指南使用 Strimzi Operator 作为 EKS 上的自我管理 Kafka 方案。Operator 会协调 Pods、存储、监听器、证书和升级；但它不会免除你在数据、可用性和安全策略方面的责任。第 6 部分会比较 Amazon MSK 等托管替代方案。
最后更新：October 16, 2026。Strimzi 1.3.0 / Kafka 4.3.1。 升级要求：Strimzi 1.0 及更高版本仅支持 CRD API
v1。升级 Operator 之前，请按照官方迁移流程转换现有的v1beta2/v1beta1/v1alpha1资源并准备 CRD。仅更改版本号并不构成升级计划。
Strimzi 1.3.0 支持 Kafka 4.2.0、4.2.1、4.2.2、4.3.0 和 4.3.1，默认使用 4.3.1。本指南固定使用兼容的组合；安装前也请检查发行版、Kubernetes 版本和升级路径。
核心架构概念
Broker 存储主题分区副本。KafkaConsumer 组会分配分区，一个成员可能拥有多个分区。独立的控制器仲裁组负责管理元数据 Raft 日志。
KRaft 于 2.8 版作为早期访问功能推出，并于 3.3 版达到生产就绪状态；Kafka 4.0 移除了 ZooKeeper 模式。控制器和 Broker 可以采用专用角色。移除 ZooKeeper 并不意味着无需再进行控制器、存储或恢复操作。
用户声明 Kafka 和 KafkaNodePool 等自定义资源；Strimzi 会协调 Pods、PVCs、Services 和 Secrets。下图是简化的关系示意图，并非高可用副本数量部署规范。
深入解析目录
- Broker 和主题/分区结构
- 复制和持久性保证
- 消费者组和偏移量管理
- KRaft 控制器仲裁架构
- 安装和配置 Strimzi
- 详细介绍
Kafka和KafkaNodePoolCRD - 在 EKS 上部署 Kafka 集群
- 使用 EBS/gp3 设计存储
- Broker 扩展策略
- 使用 Cruise Control 重新平衡分区
- 通过兼容性和可用性检查执行滚动升级
- 设计 Avro/Protobuf Schema
- Karapace 与 Apicurio Registry 的比较
- 兼容性策略：BACKWARD/FORWARD/FULL
5. Kafka Connect 和 MirrorMaker
- 部署 Kafka Connect 并配置连接器
- 运行源连接器和接收器连接器
- 使用 MirrorMaker2 进行灾难恢复和跨区域复制
- Amazon MSK 与自我管理的 Strimzi
- 使用 MSK Connect
- 与 Kinesis Data Streams 集成并进行比较
- 使用 Prometheus/Grafana 收集 Broker 指标
- 监控消费者滞后
- 使用 KEDA 自动扩缩消费者
- 分区数量和键设计策略
- 生产者/消费者性能调优
- 使用 mTLS/SASL 保护安全
- 优化存储和实例成本
- 测量基于 gp3 卷的 3-Broker KRaft 集群在 RF3 与 RF1 下的摄取上限
- 比较 acks=0/1/all 下的吞吐量与 p99 延迟权衡
- 按压缩编解码器和记录大小比较吞吐量与 CPU 成本
- 冷消费者和混合工作负载如何影响生产者吞吐量
参考资料
测验
要测试你对本节内容的掌握程度，请尝试 Kafka 基础知识测验。要检查你是否能够将基准测试数据转化为设计决策，也可以尝试 Kafka 实测基准测试测验。