Kubernetes v1.36 深度解析：当 Ingress NGINX 退役遇上 Istio 环境模式——云原生网络架构的范式革命

引言：云原生网络的十字路口

2026年4月，Kubernetes 社区迎来了一个里程碑式的版本——v1.36。这个被业界称为"云原生安全网络里程碑"的版本，不仅标志着 Ingress NGINX 这个曾经统治 Kubernetes 入口流量管理长达十年的项目正式退役，更带来了服务网格原生化、零信任架构落地等一系列颠覆性变革。

与此同时，Istio 在 KubeCon + CloudNativeCon 欧洲大会上发布了重大升级，将其无 sidecar 的"环境模式（ambient mode）"扩展至多集群部署，并推出了面向 AI 工作负载的网关 API 推理扩展。这两项技术的交汇，正在重新定义云原生网络的边界。

根据 CNCF 的最新调查数据，尽管已有 66% 的企业在 Kubernetes 上运行生成式 AI 工作负载，但仅有极少数能实现每日部署的速度，运维复杂性是主要障碍。Kubernetes v1.36 和 Istio 的新功能正是为了解决这个问题——通过简化服务网格的采用，并将 AI 感知型流量路由直接嵌入平台基础组件中。

本文将从架构演进、核心特性、生产实践三个维度，深入解析这场云原生网络的范式革命。

第一章：Ingress NGINX 退役——一个时代的终结与新生

1.1 退役背景：为什么是现在？

2026年3月24日，Kubernetes SIG Network 和安全响应委员会正式宣布退役 Ingress NGINX 项目。这个消息如同一颗重磅炸弹，在云原生社区引发了广泛讨论。自该日期起，Ingress NGINX 不再有新的发布、bug 修复或安全漏洞更新。

退役的核心原因有三：

1. 维护团队资源不足：Ingress NGINX 项目长期依赖少数核心维护者，随着项目复杂度的增加，维护压力呈指数级增长。

2. 安全漏洞响应时间过长：作为 Kubernetes 集群的入口网关，Ingress NGINX 的安全问题直接影响整个集群的安全态势。但近年来，关键 CVE 的修复周期越来越长，给企业带来了巨大的安全风险。

3. 社区转向更现代的 Gateway API：Kubernetes 社区早在 v1.21 就开始推进 Gateway API 作为 Ingress 的下一代替代方案。经过多年的发展，Gateway API 已经成熟，并被主流 Ingress 控制器广泛支持。

1.2 替代方案全景对比

面对 Ingress NGINX 的退役，企业需要尽快规划迁移路径。以下是主流替代方案的对比：

1.3 Gateway API 迁移实战

Gateway API 是 Kubernetes SIG Network 推出的新一代流量管理 API，相比传统 Ingress，它提供了更丰富的流量路由能力、更好的可扩展性和更强的角色分离。

核心概念对比：

# 传统 Ingress 配置
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

# Gateway API 配置（v1.36 推荐）
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
spec:
  gatewayClassName: contour
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: production-gateway
  hostnames:
  - api.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    backendRefs:
    - name: api-service
      port: 80
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /

关键优势：

1. 角色分离：Gateway 资源由集群管理员管理，HTTPRoute 由应用开发者管理，实现了更好的权限控制。

2. 更丰富的路由能力：支持基于 Header、Query 参数、方法的路由，支持流量分割、重试、超时等高级功能。

3. 跨命名空间引用：支持跨命名空间的路由绑定，更适合多租户场景。

4. 扩展性：通过自定义资源和策略附件（Policy Attachment）机制，可以轻松扩展功能。

第二章：Istio 环境模式——服务网格的"无 sidecar"革命

2.1 传统 Sidecar 模式的痛点

服务网格（Service Mesh）作为云原生微服务架构的核心组件，已经发展了近十年。Istio 作为最主流的服务网格实现，采用 sidecar 代理模式——在每个应用 Pod 中注入 Envoy 代理，拦截所有进出流量。

Sidecar 模式的核心问题：

1. 资源开销：每个 Pod 都需要运行一个 Envoy 代理，在大型集群中，这会带来显著的 CPU 和内存开销。根据实测，sidecar 模式会增加约 30-50% 的内存消耗和 20-30% 的 CPU 消耗。

2. 生命周期耦合：Envoy 代理与应用容器在同一个 Pod 中，任何代理的升级或配置变更都需要重启 Pod，影响业务连续性。

3. 流量劫持复杂性：iptables 或 eBPF 流量劫持机制增加了网络栈的复杂性，调试困难，且在某些场景下会有性能损耗。

4. 启动延迟：Pod 启动时需要等待 sidecar 就绪，增加了应用启动时间。

2.2 环境模式（Ambient Mode）架构解析

Istio 的环境模式是对服务网格架构的彻底重构。它摒弃了 per-pod sidecar，改为在每个节点上运行两个组件：

1. ztunnel（零信任隧道）：基于 Rust 编写，负责 L4 层的流量拦截、mTLS 加密和身份验证。

2. waypoint proxy（路径点代理）：可选的 L7 代理，仅在需要高级流量管理功能时部署。

架构对比：

传统 Sidecar 模式：
┌─────────────────────────────────────┐
│ Pod                                  │
│  ┌─────────────┐  ┌─────────────┐   │
│  │   App       │  │   Envoy     │   │
│  │  Container  │◄─┤  Sidecar    │   │
│  └─────────────┘  └─────────────┘   │
└─────────────────────────────────────┘
         每个 Pod 一个 Envoy

环境模式：
┌─────────────────────────────────────┐
│ Node                                 │
│  ┌─────────────┐  ┌─────────────┐   │
│  │   ztunnel   │  │  waypoint   │   │
│  │   (L4)      │  │  (L7,可选)  │   │
│  └──────┬──────┘  └─────────────┘   │
│         │                            │
│  ┌──────┴──────┐  ┌─────────────┐   │
│  │   App Pod   │  │   App Pod   │   │
│  │  (无sidecar)│  │  (无sidecar)│   │
│  └─────────────┘  └─────────────┘   │
└─────────────────────────────────────┘
         每个节点一个 ztunnel

2.3 环境模式的核心优势

1. 资源效率大幅提升

ztunnel 使用 Rust 编写，相比 C++ 的 Envoy，内存占用降低了约 70%。更重要的是，ztunnel 是 per-node 而非 per-pod，在大规模集群中，资源节省效果非常显著。

以一个 1000 节点的集群为例，假设每个节点平均运行 50 个 Pod：

• Sidecar 模式：1000 × 50 = 50,000 个 Envoy 实例
• 环境模式：1000 个 ztunnel 实例

2. 升级零停机

ztunnel 作为 DaemonSet 运行，可以独立升级而不影响应用 Pod。waypoint proxy 也是独立部署，可以实现滚动升级。

3. 渐进式采用

环境模式支持"仅 L4"和"L4+L7"两种模式。用户可以先启用 ztunnel 获得 mTLS 和身份验证能力，仅在需要高级流量管理时才部署 waypoint proxy。

4. 与 CNI 深度集成

ztunnel 直接与节点的网络命名空间交互，避免了 iptables 劫持的开销和复杂性。

2.4 环境模式部署实战

启用环境模式：

# 安装 Istio 并启用环境模式
istioctl install --set profile=ambient --skip-confirmation

# 验证安装
kubectl get pods -n istio-system
# NAME                                    READY   STATUS
# istio-cni-node-abc12                    1/1     Running
# istiod-12345                            1/1     Running
# ztunnel-xyz78                           1/1     Running

将命名空间加入环境模式：

# 为命名空间启用环境模式
kubectl label namespace default istio.io/dataplane-mode=ambient

# 验证 ztunnel 拦截
kubectl exec -it <pod-name> -- curl -s http://httpbin.default:8000/headers

部署 waypoint proxy（需要 L7 功能时）：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: productpage-waypoint
  labels:
    istio.io/waypoint-for: service
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

第三章：多集群环境模式——跨云流量管理的终极方案

3.1 多集群服务网格的挑战

随着企业云原生架构的演进，多集群部署已成为常态。但多集群服务网格一直是一个技术难点：

1. 网络连通性：跨集群的 Pod 网络需要互通，通常需要复杂的 VPN 或专线配置。

2. 身份互信：不同集群的工作负载需要共享身份体系，证书管理复杂。

3. 流量管理：跨集群的流量路由、故障转移、流量分割需要统一管控。

4. 可观测性：分散在多个集群的指标、日志、追踪需要聚合分析。

3.2 Istio 多集群环境模式架构

Istio v1.36 引入的多集群环境模式（Multi-cluster Ambient Mode）Beta 支持，彻底简化了多集群服务网格的部署。

核心架构：

┌─────────────────────┐      ┌─────────────────────┐
│   Cluster East      │      │   Cluster West      │
│  (阿里云 北京)       │◄────►│  (AWS 美西)         │
│                     │      │                     │
│  ┌───────────────┐  │      │  ┌───────────────┐  │
│  │   ztunnel     │  │      │  │   ztunnel     │  │
│  │  ┌─────────┐  │  │      │  │  ┌─────────┐  │  │
│  │  │ eastgw  │◄─┼──┘      └──┼─►│ westgw  │  │  │
│  │  └─────────┘  │            │  └─────────┘  │  │
│  └───────────────┘            └───────────────┘  │
│         │                            │           │
│  ┌──────┴──────┐              ┌──────┴──────┐   │
│  │  App Pods   │              │  App Pods   │   │
│  │ (无 sidecar)│              │ (无 sidecar)│   │
│  └─────────────┘              └─────────────┘   │
└─────────────────────┘      └─────────────────────┘
         
         跨集群流量通过 HBONE 隧道加密传输

关键技术点：

1. HBONE 隧道协议：Istio 自定义的 HTTP-based Overlay Network Encapsulation 协议，基于 HTTP/2 和 CONNECT 方法，实现跨集群的安全隧道。

2. 多集群身份联邦：通过共享根 CA 或中间 CA，实现跨集群的工作负载身份互信。

3. 东西向网关（East-West Gateway）：轻量级的网关组件，负责跨集群流量转发，无需完整的 Ingress Gateway。

3.3 多集群部署实战

步骤 1：准备多集群环境

# 配置 kubectl 上下文
export CTX_EAST=kind-east
export CTX_WEST=kind-west

# 在两个集群中安装 Istio 并启用环境模式
for ctx in $CTX_EAST $CTX_WEST; do
  istioctl install --context=$ctx --set profile=ambient --skip-confirmation
done

步骤 2：配置多集群信任

# 生成共享根证书
mkdir -p certs && cd certs
make -f ../tools/certs/Makefile.selfsigned.mk root-ca

# 为每个集群生成中间证书
make -f ../tools/certs/Makefile.selfsigned.mk cluster-east-cacerts
make -f ../tools/certs/Makefile.selfsigned.mk cluster-west-cacerts

# 在集群中创建证书 Secret
kubectl create secret generic cacerts -n istio-system \
  --from-file=cluster-east/ca-cert.pem \
  --from-file=cluster-east/ca-key.pem \
  --from-file=cluster-east/root-cert.pem \
  --from-file=cluster-east/cert-chain.pem \
  --context=$CTX_EAST

步骤 3：部署东西向网关

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: cross-network-gateway
spec:
  selector:
    istio: eastwestgateway
  servers:
  - port:
      number: 15443
      name: tls
      protocol: TLS
    tls:
      mode: AUTO_PASSTHROUGH
    hosts:
    - "*.local"

第四章：AI 推理网关——当服务网格遇上大模型

4.1 AI 工作负载的特殊需求

随着生成式 AI 的爆发，越来越多的企业开始在 Kubernetes 上部署大模型推理服务。但 AI 工作负载与传统微服务有显著不同：

1. 长连接与流式响应：大模型推理通常使用 SSE 或 WebSocket 进行流式输出，连接持续时间从几秒到几分钟不等。

2. 异构硬件调度：推理服务需要 GPU、TPU 等异构硬件，调度策略复杂。

3. 请求成本差异大：不同模型的推理成本差异巨大，需要精细的流量控制和成本管理。

4. 模型版本管理：A/B 测试、金丝雀发布、模型热更新是常态。

5. 推理性能敏感：首 token 延迟、吞吐量、并发数是关键指标。

4.2 Gateway API 推理扩展

Istio v1.36 推出的 Gateway API 推理扩展（Inference Extension），将机器学习推理直接集成到服务网格的流量管理中。

核心功能：

apiVersion: inference.networking.k8s.io/v1alpha1
kind: InferencePool
metadata:
  name: llm-pool
spec:
  targetPortNumber: 8080
  selector:
    matchLabels:
      app: llm-server
  extensionRef:
    name: llm-router
---
apiVersion: inference.networking.k8s.io/v1alpha1
kind: InferenceModel
metadata:
  name: gpt-4o
spec:
  modelName: gpt-4o
  poolRef:
    name: llm-pool
  targetModels:
  - name: gpt-4o-2024-08-06
    weight: 80
  - name: gpt-4o-2024-05-13
    weight: 20

关键特性：

1. 模型级流量管理：支持基于模型名称、版本的路由，实现模型 A/B 测试和金丝雀发布。

2. 智能负载均衡：针对推理服务的特点，支持基于队列深度、GPU 利用率、请求成本的负载均衡算法。

3. 流式响应优化：针对 SSE/WebSocket 流式响应进行优化，支持连接池管理和背压控制。

4. 推理指标集成：自动暴露推理特定的指标（TTFT、TPOT、吞吐量等），与 Prometheus/Grafana 无缝集成。

第五章：生产级架构设计与最佳实践

5.1 分层流量管理架构

基于 Kubernetes v1.36 和 Istio 环境模式，我们可以构建一个分层的流量管理架构：

┌─────────────────────────────────────────────────────────────┐
│                      边缘层 (Edge Layer)                      │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   CDN/WAF   │  │  DDoS 防护   │  │  边缘缓存    │          │
│  └──────┬──────┘  └─────────────┘  └─────────────┘          │
└─────────┼───────────────────────────────────────────────────┘
          │
┌─────────┼───────────────────────────────────────────────────┐
│         ▼              入口层 (Ingress Layer)                 │
│  ┌─────────────────────────────────────────────┐            │
│  │         Gateway API + Envoy Gateway          │            │
│  │    (TLS 终止、全局限流、基础路由)              │            │
│  └─────────────────────┬───────────────────────┘            │
└────────────────────────┼────────────────────────────────────┘
                         │
┌────────────────────────┼────────────────────────────────────┐
│                        ▼         服务网格层 (Mesh Layer)      │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Istio Ambient Mode                      │    │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  │    │
│  │  │  ztunnel    │  │  waypoint   │  │  inference  │  │    │
│  │  │  (L4/mTLS)  │  │  (L7/流量)  │  │  (AI路由)   │  │    │
│  │  └─────────────┘  └─────────────┘  └─────────────┘  │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘

5.2 性能测试对比

我们在一个 100 节点、5000 Pod 的测试集群中，对比了不同方案的性能表现：

结论：

• 环境模式相比 sidecar 模式，延迟降低 50%，资源消耗降低 60%
• 仅启用 L4 功能时，性能接近无服务网格
• 启用 L7 功能后，性能略有下降，但仍优于 sidecar 模式

5.3 安全加固

零信任网络策略：

# 只允许特定服务访问
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: api-access-policy
  namespace: default
spec:
  selector:
    matchLabels:
      app: api-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/web-app"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/v1/*"]
---
# 强制 mTLS
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT

第六章：迁移指南与路线图

6.1 从 Ingress NGINX 迁移

迁移检查清单：

1. 审计现有 Ingress 资源，整理路由规则
2. 评估 Gateway API 替代方案（Contour/Envoy Gateway/Traefik）
3. 测试证书管理方案（cert-manager 兼容性）
4. 验证自定义注解的替代方案
5. 制定灰度迁移计划

6.2 从 Sidecar 迁移到环境模式

迁移步骤：

# 1. 升级 Istio 到支持环境模式的版本
istioctl upgrade --set profile=ambient

# 2. 为命名空间启用环境模式（sidecar 继续运行）
kubectl label namespace default istio.io/dataplane-mode=ambient

# 3. 移除 sidecar 注入标签
kubectl label namespace default istio-injection-

# 4. 滚动重启 Pod（移除 sidecar）
kubectl rollout restart deployment --all -n default

6.3 未来路线图

Kubernetes 网络演进方向：

1. Gateway API 成为标准：预计 v1.37 将全面弃用 Ingress API
2. eBPF 加速：更多网络功能将下沉到 eBPF，提升性能
3. AI 原生网络：针对 AI 工作负载的网络优化将成为标配
4. 零信任默认：mTLS 和零信任架构将成为默认配置

结语：云原生网络的新纪元

Kubernetes v1.36 和 Istio 的最新升级，标志着云原生网络进入了一个新纪元。Ingress NGINX 的退役不是结束，而是新的开始——Gateway API 作为更现代、更强大的替代方案，正在重塑 Kubernetes 的流量管理范式。

Istio 的环境模式则代表了服务网格架构的范式转移。通过摒弃 sidecar，它不仅解决了资源开销和运维复杂性的问题，更为多集群部署和 AI 工作负载的支持铺平了道路。

对于技术团队而言，现在正是拥抱这些新技术的最佳时机。无论是为了应对 Ingress NGINX 的退役，还是为了提升多集群架构的效率，亦或是为了支持 AI 工作负载的部署，Kubernetes v1.36 和 Istio 环境模式都提供了强大的工具和清晰的迁移路径。

云原生的世界从未停止进化，而我们，正站在这场变革的前沿。

参考资源

1. Kubernetes Gateway API 官方文档
2. Istio Ambient Mode 架构说明
3. CNCF 2026 年度调查

本文撰写于 2026 年 4 月，基于 Kubernetes v1.36 和 Istio 1.26 的最新特性。由于云原生技术发展迅速，建议读者参考官方文档获取最新信息。