Istio严格模式下Init容器配置excludeOutboundIPRanges仍通信失败

你当前配置不生效的核心原因有两点：

• Istio的Init容器执行顺序和流量逻辑不符合预期：Istio注入的istio-init容器会作为Pod内第一个运行的Init容器，提前完成iptables流量劫持规则写入。你配置的traffic.sidecar.istio.io/excludeOutboundIPRanges: 0.0.0.0/0虽然会让iptables不把出站流量重定向到本地sidecar，但此时你的curl Init容器发出的是明文HTTP请求，而对端application-A开启了严格mTLS模式，会直接拒绝所有未携带合法mTLS证书的明文入站流量，连接自然失败。
• 你参考的配置逻辑不适用于当前集群环境：你使用的istio-init流量劫持方案和istio-cni方案的流量拦截逻辑存在差异，直接套用cni场景的出站排除配置，无法解决Init容器执行时sidecar未就绪、mTLS握手能力缺失的核心问题。

以下方案完全兼容istio-init组件 + Istio严格mTLS模式，不需要部署istio-cni，也不需要降低服务的mTLS安全等级：

1. 先移除之前添加的traffic.sidecar.istio.io/excludeOutboundIPRanges: 0.0.0.0/0注解，恢复Istio默认的流量劫持逻辑。
2. 在主应用Deployment的Pod模板中添加如下注解，开启sidecar启动协调能力（Istio 1.10及以上版本支持，低版本可跳过该步）：

spec:
  template:
    metadata:
      annotations:
        proxy.istio.io/config: |
          holdApplicationUntilProxyStarts: true

3. 在主应用的Init容器列表最前面（必须在你原有执行业务curl逻辑的Init容器之前），插入sidecar就绪检查容器，确保业务Init容器执行时本地Envoy代理已经完全启动、mTLS证书和路由规则加载完成：

spec:
  template:
    spec:
      initContainers:
        # 新增的sidecar等待容器，优先级高于业务Init容器
        - name: wait-istio-proxy-ready
          image: curlimages/curl:8.5.0
          command: ["/bin/sh", "-c"]
          args:
            - |
              echo "Waiting for Istio sidecar to finish initialization..."
              until [ "$(curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:15000/ready)" = "200" ]; do
                sleep 1
              done
              echo "Sidecar is ready, proceed to run init logic."
        # 原有执行业务curl逻辑的Init容器，访问逻辑不需要修改
        - name: init-curl-access
          image: curlimages/curl:8.5.0
          command: ["/bin/sh", "-c"]
          args:
            - |
              # 替换为你实际访问application-A的curl命令
              curl -f http://application-a.<your-namespace>.svc.cluster.local:80
      containers:
      # 原有业务容器、Istio自动注入的sidecar容器保持默认配置即可，不需要手动修改

调整后Pod的启动流程完全符合Istio严格模式的通信要求：

1. 首先运行istio-init容器，完成iptables流量劫持规则配置
2. 启动所有普通容器（包括Istio Envoy sidecar和你的业务容器，holdApplicationUntilProxyStarts配置会让业务容器暂时阻塞，直到sidecar就绪）
3. 按顺序运行Init容器：先执行wait-istio-proxy-ready轮询本地sidecar的15000健康检查端口，确认sidecar完全就绪后，再运行业务curl Init容器
4. 业务Init容器发出的访问application-A的流量会被iptables正常劫持到本地sidecar，由sidecar自动完成和对端application-A sidecar的mTLS握手、证书校验，全程走加密链路，符合严格mTLS的校验要求，连接可正常建立。

注意：不建议通过将application-A的mTLS模式改为PERMISSIVE的方式绕过校验，这种方式会破坏严格mTLS的零信任安全边界，生产环境禁止使用。

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