Istio sidecar为何不支持DNS直连？1.4.10如何访问外部服务

Istio Sidecar 默认不支持DNS直连外部服务的核心原因 #

• 1.4版本的Sidecar默认靠iptables规则拦截所有出站流量，所有请求必须先过Envoy代理做转发校验。这套拦截逻辑是按目标IP做路由匹配的，Envoy根本不会管业务容器DNS解析出来什么IP，更不会跟着解析结果动态更新放行列表，设计之初就是优先满足全链路管控、安全审计的需求，默认没给无管控的透传留通道。
• 这个版本默认出站流量策略是REGISTRY_ONLY，只有提前用ServiceEntry注册过的外部服务IP/网段才能被放行，没注册的外部IP请求直接被拒。加上当时版本没有内置DNS动态追踪能力，一旦外部服务换了IP，之前配的静态ServiceEntry规则直接失效。
• 1.4版本带的Envoy本身也没做动态DNS上游更新的能力，做不到业务容器解析到哪个IP，代理就自动放行哪个IP，属于版本迭代期的功能缺失，后续高版本才慢慢补上DNS代理、智能解析这类能力。

1.4.10版本实现DNS直连外部服务的可行方案 #

无需提前感知外部服务IP变更，也可满足不对该部分流量做管控的诉求，有两种可落地的方案：

• 方案1：调整全局出站流量策略为透传模式
  修改istio系统命名空间下的mesh配置，将出站流量模式从默认的REGISTRY_ONLY改为ALLOW_ANY，配置完成后所有未匹配到集群内服务、未注册ServiceEntry的流量，都会被Envoy直接透传到原始目标地址，业务容器自行完成DNS解析，外部服务IP变更也不会影响连通性。这个方案改动最小，配置完几秒就生效，不需要重启业务Pod。
  配置示例如下：

  # 编辑istio全局配置ConfigMap
  kubectl edit configmap istio -n istio-system
  # 在mesh配置段修改/新增outboundTrafficPolicy配置
  data:
    mesh: |-
      outboundTrafficPolicy:
        mode: ALLOW_ANY
  

• 方案2：针对特定业务Pod绕过Sidecar拦截
  如果不想全局放开透传规则，可以给需要直连外部服务的业务Pod添加流量拦截范围注解，让Sidecar只拦截集群内部私网网段的流量，所有外部公网流量直接走宿主机网络栈，完全不经过Envoy代理，由业务容器自行完成DNS解析和请求转发，性能损耗为0，也完全不受外部IP变更影响。
  注解配置示例：

  # 在业务Pod的metadata.annotations段添加如下注解
  annotations:
    traffic.sidecar.istio.io/includeOutboundIPRanges: "10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
  

注意：以上两种方案下的直连流量都不会被Istio采集监控指标、执行流量管控策略，完全匹配无管控直连的诉求。

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