envoy v1.33.13¶

为什么要使用 Envoy¶

在微服务的迷宫中，你是否曾感到迷失？服务间的通信像一场没有指挥的喧嚣舞会，混乱、低效且危机四伏。传统的API网关和负载均衡器如同老旧的交通灯，僵化而迟钝，难以应对瞬息万变的流量洪流与复杂的部署拓扑。这便是现代架构的核心矛盾：我们追求极致的敏捷与弹性，却被笨重的网络基础设施所拖累。

Envoy 的出现，正是为了终结这场混乱。它不是一个简单的代理，而是你服务网格的“智能中枢神经系统”。它赋予你前所未有的可见性与控制力——洞察每一次服务间调用，动态路由每一份请求，并在此过程中保障安全、提升性能。当你的系统因一个服务宕机而颤抖，或因突发流量而窒息时，Envoy 正冷静地进行熔断、重试和负载均衡。不使用 Envoy，意味着你在数字丛林中放弃了最精准的导航仪与最可靠的守卫。选择它，就是选择从被动应对到主动掌控的进化。

Envoy 是什么¶

Envoy 是一个开源的高性能边缘和服务代理，专为云原生应用设计。它通常以“边车”模式与应用程序容器并行运行，透明地处理服务间所有入站和出站网络流量。其核心功能包括动态服务发现、负载均衡、TLS 终止、HTTP/2 与 gRPC 代理、可观测性指标收集，以及丰富的可扩展过滤器架构。简而言之，Envoy 是你的微服务通信的智能交通指挥系统。

入门示例¶

场景： 一个简单的电商应用，包含一个面向用户的 frontend 服务和一个提供产品数据的 product-service 后端服务。

目标： 使用 Envoy 作为 frontend 服务的边车代理，将所有对 /api/products 的请求转发到 product-service。

开发示例：

1. 定义 Envoy 配置 (envoy.yaml): 此配置定义了一个监听 8080 端口的监听器，并将匹配路径的请求路由到目标集群。

   static_resources:
     listeners:
     - name: listener_0
       address:
         socket_address: { address: 0.0.0.0, port_value: 8080 }
       filter_chains:
       - filters:
         - name: envoy.filters.network.http_connection_manager
           typed_config:
             "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
             codec_type: AUTO
             stat_prefix: ingress_http
             route_config:
               name: local_route
               virtual_hosts:
               - name: local_service
                 domains: ["*"]
                 routes:
                 - match: { prefix: "/api/products" }
                   route: { cluster: product_service_cluster } # 路由到集群
             http_filters:
             - name: envoy.filters.http.router
               typed_config: { "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router }
     clusters:
     - name: product_service_cluster
       connect_timeout: 2s
       type: STRICT_DNS # 使用 DNS 进行服务发现
       lb_policy: ROUND_ROBIN
       load_assignment:
         cluster_name: product_service_cluster
         endpoints:
         - lb_endpoints:
           - endpoint:
               address:
                 socket_address:
                   address: product-service # 后端服务主机名（例如 K8s Service 名）
                   port_value: 50051 # 后端服务端口
   

2. 使用 Docker 运行 Envoy:

   docker run -d --name envoy-proxy \
     -p 8080:8080 \
     -v $(pwd)/envoy.yaml:/etc/envoy/envoy.yaml \
     envoyproxy/envoy:v1.33-latest
   

3. 测试:

   • 你的 frontend 服务现在不再直接调用 product-service:50051。
   • 它只需访问本地的 Envoy 代理 http://localhost:8080/api/products。
   • Envoy 会接收请求，并根据配置将其转发到真实的 product-service。

这个示例展示了 Envoy 作为透明代理的基本模式。在实际生产环境中，通常会使用更动态的配置（通过 xDS API）和更复杂的过滤器链。

Envoy v1.33.13 版本更新了什么¶

该版本主要是一个包含多项重要安全修复的补丁更新。 1. 修复了在配置远程 JWKS 获取时 JWT 认证可能导致的崩溃漏洞。 2. 解决了 TLS 证书匹配器在处理包含嵌入空字节的证书时可能出现的误判问题。 3. 修复了在 CONNECT 升级后，早期数据可能导致潜在请求走私的安全漏洞。 4. 提供了对应的 Docker 镜像和更新文档。 5. 建议所有用户升级以修复上述安全问题。

更新日志¶

版本：v1.33.13

安全修复： * CVE-2025-64527：当 JWT 身份验证配置为远程获取 JWKS 时，Envoy 可能发生崩溃。 * CVE-2025-66220：用于 match_typed_subject_alt_names 的 TLS 证书匹配器可能会错误地处理包含嵌入空字节的证书。 * CVE-2025-64763：CONNECT 升级后，来自早期数据的潜在请求走私风险。

相关资源： * Docker 镜像：https://hub.docker.com/r/envoyproxy/envoy/tags?page=1&name=v1.33.13 * 文档：https://www.envoyproxy.io/docs/envoy/v1.33.13/ * 发布说明：https://www.envoyproxy.io/docs/envoy/v1.33.13/version_history/v1.33/v1.33.13 * 完整变更日志：https://github.com/envoyproxy/envoy/compare/v1.33.12...v1.33.13

总结¶

总而言之，Envoy v1.33.13 版本是一个关键的安全更新，重点修复了三个可能导致服务崩溃、证书误判或请求走私的高危漏洞，所有用户应及时升级以确保系统安全。