配置多主机Istio EgressGateway遇503错误及DestinationRule subset复用疑问求解

Egress Gateway本质是集群内部署的一组带istio: egressgateway标签的Pod，对外暴露为集群内Service istio-egressgateway.istio-system.svc.cluster.local。
之前你接触的DestinationRule（DR）逻辑没有变化：DR始终是给指定的Service定义流量转发规则、划分流量子集（subset）。区别只是DR的host从业务后端服务换成了Egress Gateway自身的Service。
官方表述「DestinationRule中的subset字段需为其他主机复用」的真实含义：

• 不需要为每个需要走Egress的外部主机，单独部署一套Egress Gateway、单独写一套DR。所有外部流量的转发目标，最终都是落到同一个Egress Service上。
• 在指向Egress Service的DR里定义的subset，是用来给不同来源的流量挂载差异化策略（比如不同的连接超时、熔断阈值、流量灰度规则），所有外部主机的流量都可以复用这些subset的能力，不需要重复配置。subset本身和外部主机没有一一绑定的关系。

逐条对应你写的配置中的问题：

1. 资源命名空间隔离导致Egress代理加载不到规则
   你把Gateway、VirtualService、ServiceEntry都放在自定义命名空间env-specific-egress-experiments，但Egress Gateway的Pod运行在istio-system命名空间。按照Istio的默认加载规则，每个Envoy代理只会加载自身所在命名空间、以及全局标记共享的网络配置，自定义命名空间里的规则不会被istio-system里的Egress代理感知。
2. DR的subset定义完全无效
   你在DR里写的两个subset：

   subsets:
   - name: hn
   - name: slashdot
   

   没有配置任何Pod匹配规则，也没有关联任何流量策略。Istio根本不知道这两个subset对应哪些后端实例，流量路由到不存在的upstream集群时，会直接返回503。
3. 无实际需求的subset引用造成路由断裂
   你在VirtualService里把流量转到Egress Gateway时指定了不存在的subset，进一步触发路由失败。

按照多主机流量转发的最小必要配置调整，所有绑定Egress的资源统一放在istio-system命名空间，确保Egress代理能正常加载：

1. Gateway配置 #

直接监听所有需要转发的外部主机的HTTP端口：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-egressgateway
  namespace: istio-system
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
     - news.ycombinator.com
     - www.slashdot.org

2. ServiceEntry配置 #

定义外部主机的访问入口，让Egress代理能解析到目标地址：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: news-ycombinator-com
  namespace: istio-system
spec:
  hosts:
  - news.ycombinator.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: www-slashdot-org
  namespace: istio-system
spec:
  hosts:
  - www.slashdot.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS

3. VirtualService配置 #

拆成两段路由规则：集群内sidecar收到的访问外部主机的请求，统一转到Egress Gateway的80端口；Egress Gateway收到的转发请求，再转到真实外部地址。全程不需要引用subset：

# Hacker News 路由规则
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-egress-hn
  namespace: istio-system
spec:
  hosts:
  - news.ycombinator.com
  gateways:
   - mesh
   - istio-egressgateway
  http:
  # 集群内流量匹配规则：把Pod发出的访问HN的请求转到Egress
  - match:
    - gateways: ["mesh"]
      port: 80
    route:
    - destination:
       host: istio-egressgateway.istio-system.svc.cluster.local
       port:
         number: 80
  # Egress网关侧匹配规则：把收到的请求转到真实外部地址
  - match:
    - gateways: ["istio-egressgateway"]
      port: 80
    route:
    - destination:
        host: news.ycombinator.com
        port:
          number: 80

# Slashdot 路由规则，逻辑与HN完全一致
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-egress-slashdot
  namespace: istio-system
spec:
  hosts:
  - www.slashdot.org
  gateways:
   - mesh
   - istio-egressgateway
  http:
  - match:
    - gateways: ["mesh"]
      port: 80
    route:
    - destination:
       host: istio-egressgateway.istio-system.svc.cluster.local
       port:
         number: 80
  - match:
    - gateways: ["istio-egressgateway"]
      port: 80
    route:
    - destination:
        host: www.slashdot.org
        port:
          number: 80

4. DR与subset的正确使用场景 #

只有当你需要给不同流量配置差异化策略时，才需要在指向Egress Service的DR里定义subset。比如给HN的流量配30s的空闲超时，给Slashdot的流量配10s的空闲超时，示例配置：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: dr-egress-gateway
  namespace: istio-system
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
  subsets:
  - name: hn
    trafficPolicy:
      connectionPool:
        http:
          idleTimeout: 30s
  - name: slashdot
    trafficPolicy:
      connectionPool:
        http:
          idleTimeout: 10s

这时候你在VirtualService的路由目标里，给对应流量匹配指定的subset即可。这就是官方说的“复用”逻辑：同一个Egress服务的subset能力，服务所有外部主机的流量转发，不需要重复建设。

你提到的“抽象域名按环境映射真实后端”的需求，可以在上述框架下直接实现：

• 每个环境只需要维护自身作用域下的ServiceEntry，把抽象域名（比如mongodatabase）指向当前环境对应的真实后端地址（qa环境指mongo.qa.mycompany.com，int环境指mongo.int.mycompany.com）
• 不需要额外搭建无后端的ClusterIP服务，ServiceEntry本身就可以承担DNS解析和流量拦截的作用
• 所有环境的出口流量统一经过Egress Gateway转发，不需要重复部署网关组件

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