非default命名空间下Istio spec/hosts配置不生效原因及修复咨询

结合Istio的资源匹配逻辑和多命名空间运行特性，这类通配符hosts正常、精确域名失效的场景，核心诱因通常是三类：

• Gateway与VirtualService的主机匹配无有效交集
  Istio入口路由生效的强制条件是：Gateway配置的spec.servers.hosts列表，和关联的VirtualService的spec.hosts列表，必须存在精确匹配的交集——Istio不会对部分通配的host做匹配判定（比如Gateway配置app1.my.domain、VirtualService配置*.my.domain的场景，系统会判定无匹配交集，不会生成对应路由规则）。
  之前配置*作为hosts时，两边通配符可以无条件匹配所有请求，因此路由正常；改成具体域名后如果任意一侧存在拼写不一致（比如多空格、大小写偏差、后缀漏写），就会直接导致匹配失效。
• 跨命名空间的Gateway隐式引用失效
  虽然Gateway和VirtualService都部署在stg命名空间，但Istio 1.10版本之后调整了同命名空间资源的隐式引用逻辑：当VirtualService通过短名引用Gateway时，系统会优先在istio-system命名空间下查找匹配选择器的Gateway资源，而不是优先匹配当前命名空间的Gateway。
  这种场景下，同套配置部署在default命名空间时，短名引用会命中istio-system下的默认Gateway配置所以正常运行；但部署到stg命名空间时，短名引用无法正确关联本命名空间的Gateway，加上hosts从通配符改成了精确值，就没有有效路由规则绑定到入口网关。
  额外说明：stg命名空间开启istio-injection=enabled本身不会影响入口网关的路由逻辑，注入侧车的工作负载只处理网格内东西向流量，不会接管入口网关收到的外部请求，这个标签不会直接导致路由失效。
• 同命名空间下的路由规则冲突
  stg命名空间开启注入后，如果之前部署过其他关联ingressgateway的Gateway/VirtualService资源，且这些资源的hosts也匹配app1.my.domain，Istio会按照资源创建时间的优先级做路由覆盖，导致新配置无法生效；而default命名空间下没有这类冲突资源，因此配置可以正常工作。

按照以下顺序调整配置即可解决问题：

• 统一校验双端的hosts配置
  确保Gateway和VirtualService的hosts值完全一致，无拼写差异：

# Gateway配置段示例
servers:
- port:
    number: 80
    name: http
    protocol: HTTP
  hosts:
  - "app1.my.domain"

# VirtualService配置段示例
spec:
  hosts:
  - "app1.my.domain"

• 修正VirtualService的Gateway引用写法
  在VirtualService的gateways字段中，显式带上Gateway所在的命名空间后缀，不要只写短名；同时将destination的服务地址改为完整FQDN，避免短名解析歧义：

spec:
  hosts:
  - "app1.my.domain"
  gateways:
  - "gateway.stg"  # 格式固定为 <gateway名称>.<gateway所在命名空间>
  http:
  - route:
    - destination:
        host: nginx.stg.svc.cluster.local
        port:
          number: 80

• 排查同命名空间的规则冲突
  执行命令kubectl get gateway,virtualservice -n stg，检查是否存在其他Gateway资源的选择器匹配istio ingressgateway、且hosts值和app1.my.domain重合的配置，删除或调整冲突的规则即可。
• 验证网关配置同步状态
  确认istio-system命名空间下的ingressgateway代理已经拉取到最新的路由规则，检查是否存在对应的app1.my.domain主机匹配配置，同时查看Gateway资源的事件日志，确认没有配置校验失败的报错。

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