多主集群环境下如何访问已发现的跨集群服务？

核心结论 #

• 可以直接通过已发现的端点访问，但不建议：你能在Cluster2看到Cluster1的webappsvc端点，理论上可直接用端点IP+端口访问，但这种方式脱离服务发现机制，一旦Cluster1的Pod扩缩容、IP变更，Cluster2的调用方会直接失效，且无负载均衡、故障转移能力。
• 规范方案是使用ServiceEntry，而非创建同名服务：创建同名Service属于临时 workaround，ServiceEntry才是Istio跨集群服务发现的标准方式，它能明确声明外部服务（Cluster1的webappsvc）的信息，让Istio Sidecar识别并管理流量。

具体实现建议 #

方案1：使用ServiceEntry（推荐） #

在Cluster2中创建ServiceEntry资源，定义Cluster1的webappsvc服务信息，示例YAML如下：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: webappsvc-cluster1
spec:
  hosts:
  - webappsvc.cluster1  # 自定义访问域名，可结合集群名做后缀
  ports:
  - number: 80  # 对应Cluster1 webappsvc的服务端口
    name: http
    protocol: HTTP
  location: MESH_INTERNAL
  resolution: DNS  # 跨集群DNS打通时用该配置，否则用STATIC并指定端点

创建完成后，Cluster2的应用即可通过webappsvc.cluster1域名访问Cluster1的服务，Istio会自动处理负载均衡、端点动态更新。

方案2：优化同名Service方式（不推荐） #

若暂时使用同名Service，建议配置为ExternalName类型，指向Cluster1服务的跨集群DNS域名，避免手动维护端点：

apiVersion: v1
kind: Service
metadata:
  name: webappsvc
spec:
  type: ExternalName
  externalName: webappsvc.cluster1.svc.cluster.local  # 替换为实际跨集群DNS地址

这种方式比手动维护端点可靠，但仍不如ServiceEntry灵活，无法利用Istio的流量治理能力（如超时、重试、熔断）。

为什么必须要有服务定义？ #

Istio的Sidecar代理（Envoy）依赖Service或ServiceEntry的元数据生成路由规则，即便端点已被发现，没有对应的服务抽象，Envoy无法识别该服务的访问规则，也无法应用Istio的流量策略。因此必须通过ServiceEntry或Service告知Sidecar：这是一个需要访问的服务，以及它的地址、端口、协议等核心信息。

内容的提问来源于stack exchange，提问作者Abhi