如何使用Istio Service Entry对象连接不同命名空间的服务？及域名后缀限制相关疑问

嘿，你碰到的这个情况其实是Istio使用中容易踩的一个隐性坑，官方文档确实没明确标注这个限制，但背后是有原因的。

先理清楚你的场景 #

你需要让同一集群不同命名空间的svcA通过固定别名访问svcB，一开始用svcB.alias这类自定义后缀作为Service Entry的hosts值怎么都不生效，换成svcB.com这类常见顶级域名后缀后就正常了，想搞清楚是不是Istio有隐含的域名后缀要求。

为什么自定义后缀会失效？ #

这和Istio Sidecar（也就是Envoy代理）的DNS解析逻辑以及Kubernetes集群的DNS配置有关：

• Kubernetes集群默认的CoreDNS会优先处理集群内部的域名后缀（比如.svc、.cluster.local），当你用.alias这种自定义后缀时，CoreDNS找不到对应的解析记录，而Istio的Service Entry需要Envoy能拦截并接管请求，这时候请求可能直接走了集群默认的DNS流程，绕过了Service Entry的路由规则。
• Envoy的默认配置里，会把符合公共顶级域名（TLD）规范的域名（比如.com、.org）优先交给Istio的服务发现逻辑处理；而自定义后缀的域名会被当成“内部域名”，直接走Kubernetes的服务解析，导致Service Entry的规则没生效。

不想用公共TLD后缀？还有这些办法 #

如果你坚持要用自定义后缀，也能通过调整配置解决：

• 修改Sidecar配置：在Sidecar Injection的配置中，添加对自定义后缀的拦截规则，让Envoy接管这些域名的解析，不让请求走集群默认DNS。
• 用VirtualService替代（同一集群跨命名场景）：其实同一集群内跨命名空间访问，不一定需要Service Entry，直接用VirtualService就能把自定义别名路由到目标服务，比如：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: svcB-vs
spec:
  hosts:
    - svcB.alias
  http:
    - route:
        - destination:
            host: svcB.svcb-ns.svc.cluster.local
            port:
              number: 80

总结一下 #

Istio并没有强制要求必须用.com、.org这类后缀，但自定义后缀的域名容易被集群DNS和Sidecar的默认配置干扰，导致Service Entry无法正确拦截请求。用公共TLD后缀是最省心的规避方式，要是想用自定义后缀，就得调整Sidecar或者DNS的相关配置来适配。

内容的提问来源于stack exchange，提问作者David S.