90%的sarama连接kubernetes中kafka失败源于advertised.listeners与dns解析不一致：pod内应用需用clusterip/headless service域名（如kafka-0.kafka-headless.default.svc.cluster.local），若硬编码外部ip则metadata返回的broker列表无法解析，导致连接卡住。
用 sarama 连接 Kubernetes 中的 Kafka 集群时连不上
90% 的连接失败不是代码问题，而是 advertised.listeners 和 DNS 解析没对齐。Kubernetes 里 Pod 间通信走的是 ClusterIP 或 Headless Service 域名（如 kafka-0.kafka-headless.default.svc.cluster.local），但 Golang 应用若用 sarama.NewClient() 直接填外部 LoadBalancer IP 或 NodePort 地址，就会在 metadata 请求阶段卡住——因为 Broker 返回的 broker list 是内部域名，客户端无法解析。
实操建议：
- 确认 Kafka CR（如 Strimzi）中
spec.kafka.externalListeners已启用，并设为type: loadbalancer或nodeport；Strimzi 会自动生成对应 Service 并注入真实 IP 到advertised.listeners - Golang 代码里不要硬编码任何 IP：用环境变量传入
KAFKA_BOOTSTRAP_SERVERS，值应为kafka-cluster-kafka-bootstrap.default.svc.cluster.local:9092（集群内调用）或10.10.10.10:32400（NodePort 外部调用） - 若必须跨命名空间访问，确保 Service 全限定域名正确：
kafka-cluster-kafka-bootstrap.kafka.svc.cluster.local，而非省略命名空间 - 加一行日志验证 DNS 可达：
net.LookupHost("kafka-cluster-kafka-bootstrap.default.svc.cluster.local")
Consumer Group 在 K8s 重启后 offset 丢失
不是 Kafka 没存 offset，是 Golang 应用没正确提交或用了临时 group.id。Kafka 默认将 offset 存在 __consumer_offsets topic，但前提是 client 显式启用自动提交且 group.id 稳定。
实操建议：
- 禁止用随机
group.id（如fmt.Sprintf("app-%d", time.Now().Unix())），必须固定，例如my-stream-processor - 初始化
sarama.Config时显式设置：config.Consumer.Return.Errors = true和config.Consumer.Offsets.Initial = sarama.OffsetNewest - 若需精确一次语义，关掉自动提交：
config.Consumer.Offsets.AutoCommit.Enable = false，并在业务逻辑处理成功后调consumer.CommitOffset() - 检查 Kafka 集群是否启用了
offsets.topic.replication.factor=3（Strimzi 默认已设），否则单副本 topic 故障时 offset 元数据直接不可读
StatefulSet 部署 Golang 流处理器时 Pod 反复 CrashLoopBackOff
常见于资源限制过严 + GC 压力大，或挂载了只读 PVC 却尝试写日志。K8s 默认容器以非 root 用户运行，而某些 Kafka 客户端库（尤其旧版 sarama）会在 /tmp 下生成临时文件。
实操建议：
- 在 Deployment/StatefulSet 的
securityContext中指定runAsUser: 1001，并确保镜像中/tmp和日志目录（如/app/logs）权限为755且属主为该 UID - 限制内存不能低于 512Mi：
resources.limits.memory: "768Mi"，否则 Go runtime GC 频繁触发 OOMKilled - 挂载空目录用于临时文件：
emptyDir: {}到/tmp，避免因 PVC 只读导致 write failed - 加健康探针：
livenessProbe.exec.command调用curl -f http://localhost:8080/healthz，避免进程假死不被发现
如何让 Golang 应用感知 Kafka Broker 扩缩容
Kafka 本身通过 metadata 请求自动同步 broker 列表，但 sarama 默认缓存 10 分钟（MetadataMaxAge），扩容后新 broker 可能长达 10 分钟不被客户端发现。
实操建议：
- 初始化 config 时调低刷新间隔：
config.Metadata.RefreshFrequency = 30 * time.Second - 监听
sarama.Client的Errors()channel，捕获ErrLeaderNotAvailable或ErrUnknownTopicOrPartition后主动触发client.RefreshMetadata() - 不要在启动时一次性拉取所有 topic 列表做预校验——这会阻塞启动，且 topic 动态创建时仍需 runtime 发现
- 若用 Strimzi，Broker 扩容后 DNS 记录几秒内就更新，但客户端仍依赖 metadata 刷新，所以 DNS 快 ≠ 客户端立刻可用
最易被忽略的一点：Kubernetes 中的 Kafka 不是“部署完就通”，而是“配置对了才通”。Golang 应用侧的容错逻辑（重试、退避、元数据刷新）和集群侧的 advertised 配置必须咬合，差一层就表现为超时或静默丢消息。别迷信自动发现，每个环节都要有可验证的日志或指标兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
