如何跨AKS集群通过Pod名称连接目标Pod？

方案1：用ClusterIP Service + 集群DNS直接访问 #

• 在集群A里给目标Pod创建ClusterIP类型的Service，填写selector匹配Pod的标签（比如app=your-jmx-app），暴露JMX端口9090。
• 因为已经完成VNet对等，集群B的Prometheus可以直接使用Service的完整DNS地址访问：<service-name>.<namespace>.svc.cluster.local:9090/metrics。
• 优势：Service的DNS名称固定，Pod重启、IP变更都不会影响访问，无需额外组件，配置简单。

方案2：Headless Service直接解析Pod专属DNS #

• 如果需要直接指向单个Pod而非Service的负载均衡，可创建Headless Service（设置spec.clusterIP: None），同样用selector匹配目标Pod的标签。
• 每个Pod会生成唯一的DNS记录：<pod-name>.<headless-service-name>.<namespace>.svc.cluster.local，直接将该地址作为Prometheus的监控目标即可。
• 注意：如果Pod是Deployment自动生成的（带随机后缀），手动配置Pod名称会随Pod重建失效，需结合Prometheus的Kubernetes服务发现自动抓取Pod DNS。

方案3：配置跨集群DNS转发 #

• 在集群B的CoreDNS中添加转发规则，将集群A的DNS域请求转发到集群A的CoreDNS服务IP，让集群B能直接解析集群A的Pod/Service DNS。
• 先获取集群A的CoreDNS ClusterIP：执行kubectl get svc coredns -n kube-system。
• 编辑集群B的CoreDNS ConfigMap：

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: coredns
    namespace: kube-system
  data:
    Corefile: |
      .:53 {
          errors
          health
          kubernetes cluster.local in-addr.arpa ip6.arpa {
              pods insecure
              fallthrough in-addr.arpa ip6.arpa
          }
          forward . /etc/resolv.conf
          cache 30
          loop
          reload
          loadbalance
      }
      # 转发集群A的DNS请求
      cluster.local:53 {
          forward . <集群A的CoreDNS IP>
      }
  

• 重启集群B的CoreDNS Pod：kubectl rollout restart deployment coredns -n kube-system。
• 完成后，集群B的Prometheus就能直接使用集群A的Pod/Service DNS地址访问目标。

方案4：Kubernetes服务发现（动态Pod场景首选） #

• 如果Pod是动态创建的（比如Deployment扩缩容、Pod重建），手动维护目标地址效率低，可让集群B的Prometheus直接从集群A的API Server拉取Pod信息。
• 操作步骤：
  1. 在集群A创建一个具备只读权限的ServiceAccount，绑定view集群角色，用于集群B的Prometheus访问集群A的API。
  2. 导出该ServiceAccount的token：kubectl get secret <service-account-secret-name> -n <namespace> -o jsonpath='{.data.token}' | base64 -d。
  3. 在集群B的Prometheus配置中添加Kubernetes服务发现规则：

     scrape_configs:
       - job_name: 'cluster-a-jmx-metrics'
         kubernetes_sd_configs:
           - api_server: 'https://<集群A的API Server地址>'
             bearer_token: '<获取到的集群A ServiceAccount Token>'
             tls_config:
               insecure_skip_verify: true # 生产环境建议配置合法CA证书
             role: pod
         relabel_configs:
           - source_labels: [__meta_kubernetes_pod_label_app]
             action: keep
             regex: your-jmx-app-label # 仅保留带该标签的Pod
           - source_labels: [__meta_kubernetes_pod_container_port_number]
             action: keep
             regex: 9090 # 仅保留暴露9090端口的Pod
           - target_label: __address__
             replacement: '$1:9090'
     

• 优势：自动发现符合条件的Pod，Pod动态变更无需手动修改配置，适配大规模、动态化的集群场景。

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