同VPC同GCP托管Istio控制平面下跨集群服务DNS访问问题

可以实现，核心是让源集群的DNS系统能正确解析到目标集群的Service IP，以下是几种实用方案：

1. 配置CoreDNS转发规则 #

如果两个集群使用CoreDNS作为DNS服务，可通过修改Corefile实现域名转发：

• 先获取cluster2的集群DNS服务IP（通常是kube-system命名空间下coredns服务的ClusterIP）
• 在cluster1的CoreDNS配置中添加针对目标命名空间域的转发规则：

test1.svc.cluster.local:53 {
    forward . <cluster2-dns-ip>
    cache 30
}

配置后，cluster1内的Pod请求test-v2.test1.svc.cluster.local时，DNS查询会被转发到cluster2的DNS服务，解析出cluster2中test-v2的ClusterIP，由于同VPC网络互通，Pod可直接访问该IP。

注意：若两个集群的Service CIDR存在重叠，需先调整CIDR避免冲突，否则可能出现解析混乱。

2. 手动添加DNS映射 #

Pod级HostAliases #

针对需要访问跨集群服务的Pod，在Deployment中直接配置hostAliases，将域名映射到目标Service的IP：

spec:
  template:
    spec:
      hostAliases:
      - ip: "<cluster2-test-v2-service-ip>"
        hostnames:
        - "test-v2.test1.svc.cluster.local"

这种方式适合少量服务的场景，但如果目标Service的IP发生变化，需要手动更新配置。

CoreDNS全局Hosts规则 #

在cluster1的CoreDNS中通过Hosts插件添加全局DNS映射，所有Pod都能生效：

hosts {
    <cluster2-test-v2-service-ip> test-v2.test1.svc.cluster.local
    fallthrough
}

3. 云厂商托管集群的跨集群服务发现 #

从你的Namespace注解来看，集群使用了ASM（Anthos Service Mesh），推测是GKE托管集群。可以开启GKE的跨集群服务发现功能：

• 该功能会自动同步同VPC内集群的Service信息到各自的DNS系统，原生的*.svc.cluster.local域名就能直接跨集群解析，无需额外配置。

必要前提 #

• 两个集群处于同一VPC，且Pod网络与目标集群的Service IP段之间无防火墙或网络策略拦截
• 目标集群的Service IP在源集群Pod的网络可达范围内

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