基于Istio/Gateway API的Kubernetes外部域名路径路由配置问题

问题分析 #

网格内工作负载访问graphql-api.mesh-external.example.com:443时使用明文HTTP协议，而目标端口期望HTTPS流量，导致SSL握手失败。核心原因是Istio Sidecar未自动对该外部服务发起TLS请求，或工作负载的请求方式未适配目标服务的协议要求。

解决方案 #

1. 优化ServiceEntry与DestinationRule配置 #

调整配置让Sidecar明确知晓该外部服务的端口需使用HTTPS协议，强化TLS策略：

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: www-example-com
spec:
  hosts:
  - graphql-api.mesh-external.example.com
  location: MESH_EXTERNAL
  ports:
  - name: https-443  # 遵循Istio端口命名规范：<协议>-<端口>，帮助Sidecar识别协议
    number: 443
    protocol: HTTPS
  resolution: DNS
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: www-example-com
spec:
  host: graphql-api.mesh-external.example.com
  trafficPolicy:
    # 全局配置TLS策略，确保所有发往该服务的流量都使用TLS
    tls:
      mode: SIMPLE
      sni: graphql-api.mesh-external.example.com

2. 配置VirtualService处理内部HTTP请求（可选） #

如果网格内工作负载习惯用HTTP协议访问该域名（如http://graphql-api.mesh-external.example.com），添加VirtualService自动将HTTP请求转为HTTPS：

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: graphql-api-redirect-vs
spec:
  hosts:
  - graphql-api.mesh-external.example.com
  http:
  # 匹配80端口的HTTP请求，重定向到HTTPS
  - match:
    - port: 80
    redirect:
      scheme: https
      authority: graphql-api.mesh-external.example.com
  # 确保443端口的请求通过TLS转发
  - match:
    - port: 443
    route:
    - destination:
        host: graphql-api.mesh-external.example.com
        port:
          number: 443
    tls:
      mode: SIMPLE
      sni: graphql-api.mesh-external.example.com

3. 验证配置生效 #

应用配置后，在网格内工作负载的Pod中执行测试：

# 测试HTTPS访问是否正常
curl -v https://graphql-api.mesh-external.example.com
# 若配置了重定向，测试HTTP访问是否自动跳转
curl -v http://graphql-api.mesh-external.example.com

关键说明 #

• 端口命名规范：Istio通过端口名称识别协议，https-443这类命名能让Sidecar更准确地处理TLS流量。
• 全局TLS策略：将TLS配置放在trafficPolicy全局节点下，避免端口级配置遗漏，确保所有流量都使用TLS。
• 重定向逻辑：解决工作负载未使用HTTPS发起请求的场景，自动纠正请求方式，避免SSL错误。

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