Istio 1.30.0 发布后不久，1.30.1 就紧随而至——原因很直接：一个 CVSS 7.5 的高危拒绝服务漏洞，加上一批在 ambient 模式、Gateway API、多集群等方向上影响生产稳定性的 bug。如果你正在跑 1.30.0，这次升级不是"可选"，而是"尽快"。
CVE-2026-47774：HTTP/2 请求可耗尽 Envoy 内存
漏洞的核心在于两处 Envoy 对 HTTP/2 头部大小的校验缺失：
- Cookie 头字节未计入请求头大小校验——攻击者可以在合法的头部大小限额内，塞入超长 Cookie，绕过限制。
- HPACK 编码字节有上限，但解码后的总头部大小没有对应限制——HPACK 压缩后体积小，解码后可以膨胀到远超预期，直接撑爆内存。
两者叠加，一个未经认证的远程攻击者只需构造特殊的 HTTP/2 请求，就能让 Envoy 进程内存飙升直至 OOM。对于暴露在公网的 Ingress Gateway 尤其危险。
升级到 1.30.1 是当前唯一的官方修复方式。 如果你暂时无法升级，可以考虑在 Ingress 前面加一层 HTTP/2 头部大小硬限制的 WAF/代理规则作为临时缓解。
nftables 后端的新防护：启动时检测 JSON 支持
Istio CNI 的原生 nftables 后端依赖 nft 二进制的 JSON 输出能力来读取配置——特别是在 Pod 移除时。但部分宿主机上的 nft 编译时未包含 JSON 支持，调用时会报 Error: JSON support not compiled-in，CNI agent 会无限重试，Pod 删除卡死。
1.30.1 在初始化阶段增加了检测：如果 nft 不支持 JSON，自动回退到 iptables 后端，而不是在运行时反复撞墙。
你可以提前确认宿主机的 nft 是否支持 JSON：
# 检查 nft 是否支持 JSON 输出
nft -j list ruleset 2>&1 | head -1
# 如果输出类似 "Error: JSON support not compiled-in"
# 说明该节点会自动回退到 iptables 后端
# 建议升级 nft 或确认 iptables 后端符合预期
# 批量检查集群所有节点
for node in $(kubectl get nodes -o name); do
echo "=== $node ==="
kubectl debug $node --image=busybox -- chroot /host nft -j list ruleset 2>&1 | head -2
done
Gateway API CRD 版本过低？istioctl 现在会明确告诉你
升级到 Istio 1.30 后，如果你集群里的 Gateway API CRD 版本低于 Istio 要求的最低版本，istiod 会静默过滤掉这些资源——TLS passthrough 突然失效，但没有任何错误提示，排查极其痛苦。
1.30.1 新增了 IST0176 检查项，专门标记 CRD 版本不足的问题：
# 运行分析，检查 Gateway API CRD 版本兼容性
istioctl analyze -A
# 如果输出包含 IST0176，说明需要升级 CRD
# 示例输出：
# IST0176: Gateway API CRDs are below the minimum required version.
# 查看当前安装的 Gateway API CRD 版本
kubectl get crd gatewayclasses.gateway.networking.k8s.io \
-o jsonpath='{.metadata.annotations["gateway.networking.k8s.io/bundle-version"]}'
发现版本过低时，按 Gateway API 官方指引升级 CRD 即可，不再需要靠猜测定位问题。
策略排除注解：让非 Istio 网关的策略不再被误翻译
当集群里同时存在 Istio 和其他网关控制器时，BackendTLSPolicy 或 XBackendTrafficPolicy 可能被 Istio 误翻译成 Envoy 配置，产生冲突。1.30.1 支持在策略对象上打注解 istio.io/ignore-policy-attachment: "true"，istiod 会直接跳过：
apiVersion: gateway.networking.k8s.io/v1alpha3
kind: BackendTLSPolicy
metadata:
name: tls-policy-for-other-gateway
annotations:
istio.io/ignore-policy-attachment: "true" # Istio 不会翻译此策略
spec:
targetRef:
group: ""
kind: Service
name: my-backend
namespace: default
tls:
caCertRefs:
- kind: ConfigMap
name: my-ca
namespace: default
hostname: my-backend.example.com
这个注解对多网关共存的混合架构非常实用——避免 Istio "抢"了本不属于它的策略。
Ambient 模式的三处关键修复
Ambient 模式在 1.30.1 中修了三个直接影响流量正确性的 bug：
1. 多网络场景下 Ingress 到 Waypoint 的路由断裂
当 Ingress 在网络 A，而目标 Service 在网络 B 且配置了 istio.io/ingress-use-waypoint 注解时，流量本应经过 Waypoint，但之前没有路由过去。1.30.1 修正了这一跨网络路由逻辑。
2. 并发 Pod 加入时的 fatal panic
两个 Pod 同时加入同一节点的 ambient mesh 时，istio-cni agent 会触发并发 map 写入的 fatal panic。这在批量部署或扩容时极易命中。修复后 CNI agent 的并发操作不再踩这个坑。
3. publishNotReadyAddresses + topology 路由导致全局健康策略被覆盖
如果一个 Service 同时设置了 publishNotReadyAddresses: true 和 PreferSameZone/PreferSameNode 流量分布，ztunnel 会错误地把 healthPolicy: AllowAll 应用到所有使用相同拓扑策略的 Service 上——流量被发到未就绪的端点，影响范围远超预期。
排查时可以检查：
# 检查是否有 Service 同时设置了 publishNotReadyAddresses 和 topology
kubectl get svc -A -o json | jq -r '.items[] |
select(.spec.publishNotReadyAddresses == true
and .spec.trafficDistribution != null) |
"\(.metadata.namespace)/\(.metadata.name): trafficDistribution=\(.spec.trafficDistribution)"'
如果输出不为空，这些 Service 在 1.30.0 上很可能已经受到影响，升级后行为会恢复正常。
其他值得关注的修复
| 修复项 | 影响 |
|---|---|
consistentHash 负载均衡在扩容后不路由到新端点 |
Envoy 回归导致 RING_HASH 环在批量更新时不重建，DestinationRule 用一致性哈希的服务扩容后流量不均衡 |
| HTTPS ListenerSet 在手动证书部署模式下不交付 TLS 证书 | Gateway + ListenerSet 的 HTTPS 场景证书丢失 |
| HTTPRoute/GRPCRoute 无效 header 值的 filter 被静默丢弃 | 配置错误无任何状态反馈，排查困难 |
| 外部 SDS provider 用 provider 名称而非 credential 名称作为资源名 | 多 Gateway 共用同一 SDS provider 时无法请求不同证书；1.30.1 修正为用 sds:// 前缀后的 credential name |
| SDS 无 UDS/扩展配置时静默失败 | 现在回退到 ADS（Kubernetes Secrets）获取证书 |
| 多集群 ClusterStore 死锁 | AllReady 递归获取 RWMutex 导致读写全部阻塞 |
| agentgateway 忽略 ListenerSet 及其路由 | 修正后 agentgateway 正确处理 ListenerSet |
| ListenerSet 未被父 Gateway 允许时状态报告错误 | Accepted 条件现在正确报告 False；ListenerSet 功能不再受 PILOT_ENABLE_ALPHA_GATEWAY_API 门控 |
升级建议
- 优先级最高的是 CVE-2026-47774——任何暴露 HTTP/2 的 Ingress Gateway 都应尽快升级。
- 使用 ambient 模式的集群，尤其是多网络拓扑或批量扩容场景，升级后能消除 panic 和路由异常。
- Gateway API 用户升级前先跑
istioctl analyze确认 CRD 版本，升级后可利用istio.io/ignore-policy-attachment注解精细控制策略归属。 - nftables 后端用户确认宿主机
nft的 JSON 支持状态，1.30.1 的自动回退机制会兜底，但了解当前状态有助于预判行为。
升级命令：
istioctl upgrade --to-version=1.30.1
升级完成后，建议再次运行分析确认集群状态：
`bash
istioctl analyze -A