Istio 1.30：AI 网关实验性登场，Ambient 模式持续补位

预计阅读时间：10 分钟

Istio 1.30 刚刚发布，正式支持 Kubernetes 1.32–1.36。这一版最值得关注的不是某个单一大功能，而是多条线同时推进——为 AI Agent 流量量身打造的数据面代理首次亮相，Gateway API 补齐 TLS 短板，Ambient 模式啃下了 CIDR 和 XFCC 两块硬骨头，流量管理新增了命名空间级继承和统一扩展 API。下面逐项拆解，并给出可直接跑的配置示例。

Agentgateway：为 AI Agent 与 MCP 流量而生的数据面

Istio 1.30 引入了实验性的 agentgateway，它不是 Envoy 的又一个 filter，而是直接替换 Gateway Pod 上的 Envoy 代理。设计目标很明确：承载 AI Agent 和 MCP（Model Context Protocol）Server 的流量模式，这类流量与传统 HTTP/GRPC 有本质差异——长连接、多路复用、工具调用协商——Envoy 能做但不够贴合。

当前限制也很清楚：

仅支持 Gateway API 的 Gateway，不能做 Sidecar 或 Waypoint
只提供一个 GatewayClass：istio-agentgateway
早期访问阶段，边界粗糙

启用方式：

# 在 istiod 上开启 agentgateway
istioctl install --set values.global.pilotEnv.PILOT_ENABLE_AGENTGATEWAY=true

# 或者直接修改 istiod Deployment 的环境变量
kubectl -n istio-system set env deployment/istiod PILOT_ENABLE_AGENTGATEWAY=true

然后创建使用 istio-agentgateway GatewayClass 的 Gateway 资源：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: ai-agent-gw
  namespace: istio-system
spec:
  gatewayClassName: istio-agentgateway
  listeners:
    - name: mcp
      port: 8080
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All

这是实验功能，生产环境暂不建议使用，但如果你正在搭建 MCP Server 的入口网关，值得在测试集群里跑一轮，把反馈提交到 Istio 社区。

Gateway API：TLSRoute 补齐与多租户可观测性

Istio 对 Gateway API 的实现一直在追赶 in-tree spec，1.30 补了两个关键缺口：

TLSRoute 终止与混合模式——此前 Istio 只支持 TLS passthrough，现在可以在 Gateway 层做 TLS 终止，也支持终止+passthrough 混合，适合同一端口上不同 SNI 路由到不同后端的场景。
东西向网关的 TLS passthrough listener——跨集群流量终于可以在东西向网关上直接透传 TLS，不再被迫做终止再重新握手。

此外，Gateway status 现在会报告已挂载的 ListenerSets 和路由，多租户共享网关时，各团队终于能从 status 里看到自己的路由是否生效，不用再靠 istioctl proxy-config 猜。

Ambient 模式：CIDR、XFCC、HBONE 调优三连

Ambient 模式在 1.30 拿到了三个实用能力：

CIDR 地址进入 ServiceEntry

此前 ServiceEntry 的 endpoints 只能逐个写 IP，对内网大段地址非常痛苦。现在可以直接用 CIDR：

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: internal-cidr-service
spec:
  hosts:
    - internal.corp.local
  location: MESH_EXTERNAL
  ports:
    - number: 443
      name: https
      protocol: HTTPS
  resolution: NONE
  endpoints:
    - address: 10.20.0.0/16  # CIDR 地址，Ambient 模式下可直接路由

这意味着 ztunnel 可以把整个 /16 的流量纳入 mesh 路由，不用逐条枚举 workload。

Waypoint 合成 XFCC 头

Ambient 模式下，ztunnel 把源工作负载的 SPIFFE 身份传给 waypoint，但上游应用拿到的连接里没有 x-forwarded-client-cert（XFCC）头。1.30 允许在 waypoint Gateway 上加注解，让 waypoint 把 SPIFFE 身份合成 XFCC：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-waypoint
  annotations:
    ambient.istio.io/xfcc-include-client-identity: "true"
spec:
  gatewayClassName: istio-waypoint
  listeners:
    - name: mesh
      port: 15088
      protocol: HBONE

上游服务现在可以从 XFCC 头里读到调用方的 SPIFFE URI，做身份校验或审计。

HBONE 流控窗口可调

高吞吐场景下，HBONE CONNECT 的默认流控窗口可能成为瓶颈。1.30 新增两个环境变量：

# 在 istiod 上调整 HBONE 窗口大小（单位：字节）
kubectl -n istio-system set env deployment/istiod \
  PILOT_HBONE_INITIAL_STREAM_WINDOW_SIZE=65536 \
  PILOT_HBONE_INITIAL_CONNECTION_WINDOW_SIZE=1048576

ztunnel 也新增了 Tokio runtime metrics，Grafana dashboard 里新增了 Resource Usage 面板——活跃 TCP 连接数、打开的 fd 和 socket 数一目了然，排查 ztunnel 资源泄漏终于有了抓手。

流量管理：继承、竞速、统一扩展

命名空间级流量分布继承

以前每个 Service 都要写 trafficDistribution: PreferClose，1.30 支持在命名空间上设注解，Service 自动继承：

apiVersion: v1
kind: Namespace
metadata:
  name: my-apps
  annotations:
    traffic.istio.io/distribution: PreferClose

命名空间内所有未显式设置 trafficDistribution 的 Service 都会走 PreferClose，减少大量重复配置。

ServiceEntry 的 RACE_FIRST_TCP_CONNECT

当 DNS 返回多个 A 记录时，新注解 istio.io/connect-strategy: RACE_FIRST_TCP_CONNECT 让客户端并发发起 TCP 连接，谁先握手成功就用谁：

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: fast-failover-svc
  annotations:
    istio.io/connect-strategy: RACE_FIRST_TCP_CONNECT
spec:
  hosts:
    - api.external.com
  location: MESH_EXTERNAL
  ports:
    - number: 443
      name: https
      protocol: HTTPS
  resolution: DNS

这对多地址外部服务（CDN、多区域入口）的冷启动延迟有明显改善。

TrafficExtension API：Wasm 与 Lua 的统一入口

WasmPlugin 作为 Envoy 扩展的主要机制，配置分散且只覆盖 Sidecar。1.30 引入 TrafficExtension API，一个 API 同时配置 Wasm 和 Lua 扩展，适用 Sidecar、Gateway 和 Waypoint：

apiVersion: extensions.istio.io/v1alpha1
kind: TrafficExtension
metadata:
  name: rate-limit-ext
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  config:
    type: WASM
    wasm:
      url: oci://registry.istio.io/ratelimit:v0.1
    configuration:
      json: |
        {"limit": "100/min"}
  phase: AUTHN

TrafficExtension 是新 API，WasmPlugin 仍可使用，但社区明确前者是未来方向。新项目建议直接用 TrafficExtension。

多 CUSTOM 授权策略

同一个工作负载上，不同 API 路径可以用不同的授权提供者——OAuth 路径走 OAuth，内部路径走 LDAP，API Key 路径走 API Key 校验——不再需要把所有认证塞进一个 Provider。

Helm v4 与安全收紧

Helm v4 支持

1.30 正式支持 Helm v4（server-side apply）。此前升级时 webhook 的 failurePolicy 字段所有权冲突是个老大难问题，现在终于解决。用 Helm v4 的团队可以直接升级，不再需要之前的 workaround。

Debug 端口强制认证

syncz、config_dump 等 XDS debug 端口（15010）现在默认要求认证（ENABLE_DEBUG_ENDPOINT_AUTH=true）。如果你需要从特定命名空间访问，可以配置白名单：

kubectl -n istio-system set env deployment/istiod \
  ENABLE_DEBUG_ENDPOINT_AUTH=true \
  DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES=dev-team,qa-team

其他安全变更

pilot-discovery 新增 --tls-min-version 参数，可抬高控制面 TLS 最低版本
Istio 镜像默认 registry 切换到 registry.istio.io（旧 registry 仍可用）
Wasm fetch 新增 SSRF 保护，二进制大小和解压限制可配置

升级清单

升级到 1.30 前需要确认的事项：

项目	动作
Debug 端口认证	检查是否有脚本或 dashboard 直接访问 15010 端口，如有则配置 `DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES` 或在请求中带上有效 token
镜像 registry	新安装默认用 `registry.istio.io`；已有集群如果镜像拉取策略是 `Always` 且网络不通新 registry，需在 Helm values 里指定 `global.hub`
TLS 最低版本	如果控制面有合规要求，在 istiod 启动参数加上 `--tls-min-version=VersionTLS12` 或更高
agentgateway	仅用于实验，不要在生产 GatewayClass 上切换
WasmPlugin → TrafficExtension	现有 WasmPlugin 配置继续工作，新扩展建议用 TrafficExtension
HBONE 窗口	高吞吐 Ambient 场景建议压测后再调 `PILOT_HBONE_INITIAL_STREAM_WINDOW_SIZE`

Istio 1.30 的主线很清晰：Ambient 模式从"能跑"走向"好用"，Gateway API 从"能用"走向"合规"，扩展机制从"碎片"走向"统一"。如果你已经在跑 Ambient 或 Gateway API，这一版值得尽快跟进；如果还在 Sidecar 模式，命名空间级继承和多 CUSTOM Provider 也能立刻减少配置负担。