https://ops.docs.72602.space/using/k8s/service_discovery/index.html 最常见的说法是 “两种核心机制”，但这指的是服务发现的两种基本模式，而不是具体的实现方式。 维度一：两种核心模式 这是从服务发现的基本原理上划分的。 基于客户端服务发现 工作原理：客户端（服务消费者）通过查询一个中心化的服务注册中心（如 Consul、Eureka、Zookeeper）来获取所有可用服务实例的列表（通常是 IP 和端口），然后自己选择一个实例并直接向其发起请求。 类比：就像你去餐厅吃饭，先看门口的电子菜单（服务注册中心）了解所有菜品和价格，然后自己决定点什么，再告诉服务员。 特点：客户端需要内置服务发现逻辑，与服务注册中心耦合。这种方式更灵活，但增加了客户端的复杂性。 基于服务端服务发现 工作原理：客户端不关心具体的服务实例，它只需要向一个固定的访问端点（通常是 Load Balancer 或 Proxy，如 Kubernetes Service）发起请求。这个端点负责去服务注册中心查询可用实例，并进行负载均衡，将请求转发给其中一个。 类比：就像你去餐厅直接告诉服务员“来份招牌菜”，服务员（负载均衡器）帮你和后厨（服务实例）沟通，最后把菜端给你。 特点：客户端无需知道服务发现的具体细节，简化了客户端。这是 Kubernetes 默认采用的方式。 维度二：Kubernetes 中具体的实现方式 在 Kubernetes 内部，我们通常讨论以下几种具体的服务发现实现手段，它们共同构成了 Kubernetes 强大的服务发现能力。 1. 环境变量 当 Pod 被调度到某个节点上时，kubelet 会为当前集群中存在的每个 Service 添加一组环境变量到该 Pod 中。 格式：{SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT。 例子：一个名为 redis-master 的 Service 会生成 REDIS_MASTER_SERVICE_HOST=10.0.0.11 和 REDIS_MASTER_SERVICE_PORT=6379 这样的环境变量。 局限性：环境变量必须在 Pod 创建之前就存在。后创建的 Service 无法将环境变量注入到已运行的 Pod 中。因此，这通常作为辅助手段。 2. DNS（最核心、最推荐的方式） 这是 Kubernetes 最主要和最优雅的服务发现方式。 工作原理：Kubernetes 集群内置了一个 DNS 服务器（通常是 CoreDNS）。当你创建一个 Service 时，Kubernetes 会自动为这个 Service 注册一个 DNS 记录。 DNS 记录格式： 同一命名空间：<service-name>.<namespace>.svc.cluster.local -> 指向 Service 的 Cluster IP。 在同一个命名空间内，你可以直接使用 <service-name> 来访问服务。例如，前端 Pod 访问后端服务，只需使用 http://backend-service。 不同命名空间：需要使用全限定域名，例如 backend-service.production.svc.cluster.local。 优点：行为符合标准，应用无需修改代码，直接使用域名即可访问其他服务。 3. Kubernetes Service Service 资源对象本身就是服务发现的载体。它提供了一个稳定的访问端点（VIP 或 DNS 名称），背后对应一组动态变化的 Pod。 Hugo en