在 kubernetes 中运行 go-zero rpc 服务，并不必然需要再部署一套独立 etcd。go-zero 官方服务发现文档截至 2026 年 11 月 11 日列出的方案中，客户端可通过 headless service 的 dns 名称定位服务。这是当前公开的寻址选项，并非新版本发布公告，也不代表所有部署环境都应切换到同一种发现方式。
官方给出的示例里，客户端的 Target 指向以 dns:/// 开头的集群域名，同时附带对应的命名空间与端口信息。文档还单独列出了直接填写 Pod Endpoint 的配置方式，明确这类方案更适配 StatefulSet 这类部署场景。域名寻址与固定地址直连两种模式各有专属配置入口，不能直接把示例中的服务名、端口参数原封不动套用到任意项目的配置中。
来源：Go-Zero 官方文档
这套 DNS 寻址能力和客户端配置逻辑完全适配。官方 gRPC 配置资料把 Etcd、Endpoints 和 Target 分别列为独立可选字段：Etcd 对应基于注册中心的服务发现模式，Endpoints 是直连的服务地址列表，Target 字段的内容则交给对应的名称解析模块处理。接入这套方案时需要确认的核心内容是当前运行环境的网络连通性及服务实际地址，不能仅依据项目是否使用了这款微服务框架就直接套用配置。
服务发现文档仍将 etcd 列为生产环境的推荐选择，同时给出了服务注册、客户端监听和多节点集群的完整示例。也就是说，该 DNS 方案并不是对 etcd 原生支持的取消。跨环境调用的服务、已有既定注册约定的存量服务和集群内部署的各类服务，都需要根据实际寻址条件做评估，不能看到这个方案就直接删除正在运行的注册中心组件。
可选择的服务发现入口变多，并不等于 Kubernetes 侧的部署配置可以省略。Go-Zero 官方 Kubernetes 文档仍完整展示了 Deployment、Service、ConfigMap 和自动扩缩容相关的资源配置。Deployment 示例分别配置 CPU 与内存的资源请求值和上限，还内置了存活探针、就绪探针的相关定义；这类资源管控与服务可用性检查逻辑，完全无法靠 DNS 域名本身替代。
来源：Go-Zero 官方文档
文档示例中的两个探针使用相同的健康检查路径，但配置的启动等待时长并不一致。所有给出的资源数值和探针路径都属于演示用例，实际部署时需要与容器本身和服务的具体实现匹配。配套的自动扩缩容示例则按 CPU 利用率动态调整服务副本数，同时设置了副本数的最小和最大边界，这也说明服务可正常发现与服务有足够承载容量，是两个完全独立的问题。
文档图片署名 go-zero contributors，按 CC BY 4.0 许可引用；图片为官方页面节选，已裁剪或等比缩放，图床另附站点水印。
这套公开的寻址方案，为已经运行在 Kubernetes 内的项目多提供了业务服务发现层面的选型方向。上线前需要逐一验证的事项仍包括集群域名可正常解析、服务端口配置匹配、实例就绪状态符合预期，以及应用配置与部署资源完全对齐；仅修改配置里的一个地址字符串，不能证明整条服务调用链已经可以正常工作。
