Traefik Proxy V3.0 正式版发布：支持 WebAssembly 和 Kubernetes Gateway API-CSDN博客

公众号关注「奇妙的 Linux 世界」

设为「星标」，每天带你玩转 Linux ！

在过去的几年里，微服务架构逐渐成为主流，越来越多的企业开始采用它来构建和部署应用。作为领先的反向代理解决方案，Traefik Proxy 也一直在不断进化，以满足开发者的需求。

近日，Traefik Proxy V3 正式发布，它带来了许多令人激动的更新，其中最引人注目的就是对 WebAssembly 和 Kubernetes Gateway API 的原生支持。

大约五年前，在 2019 年 9 月，我们发布了 Traefik 的上一个主要版本：v2.0。自那以后，Traefik 比以往任何时候都更加活跃。它取得了独特的长期牵引力，下载量超过 30 亿次，拥有 700 多名贡献者。

Traefik 在 DockerHub 上排名前 15，拥有 46,000 个 GitHub 星，并且连续五年被 OSSInsight.io 评为排名第一的 API 网关。真是了不起的旅程！

我们围绕几个关键方面设计了这个重大版本。首先，我们增加了对流行、新兴技术的支持——WebAssembly（Wasm）、OpenTelemetry 和 Kubernetes Gateway API。

当然，因为代理的核心是路由和安全，我们对路由规则的关键部分进行了翻新，并增加了对一些前沿技术的支持，如 HTTP/3、SPIFFE 和 Tailscale。

任何重大版本发布的另一个关键方面，即设计中包含重大的变更，是提供从先前版本迁移的最顺畅的用户体验。

我们不仅提供完整的迁移指南，而且还确保从之前的 v2 版本过渡到新的 v3 版本的过程已经流水线化，确保了与 v2 语法的向后兼容性，同时提供了一个逐步采用 v3 语法的途径。

最后，Traefik 一直是一个社区驱动的项目。在创建一个温馨和尊重的环境中，通过强大的明确流程帮助，已经做出了巨大的努力来改善贡献者的用户体验。

我对这个 8 年前诞生的项目已经成为现代云原生基础设施栈的关键组成部分感到无比自豪，这得益于这样一个了不起的社区的帮助。

好的，让我们深入了解 Traefik v3 的细节吧 🙂

迁移便捷性

几年前，当我们向世界推出 Traefik v2 时，团队对于改进这个项目感到非常兴奋，以至于我们低估了一件事情：从 v1.x 迁移到 v2.x 的用户体验。

我们的迁移计划并不是空白的，完全不是：我们编写了详尽的迁移指南，甚至还提供了一个迁移工具来帮助用户将他们的配置转换为新格式。但这些还不够，老实说，这个新版本的采用比我们预期的要慢得多。

显然，这不是我们希望在 Traefik v3 中再次看到的情况。主要版本意味着有破坏性变化是显而易见的，但这不应该意味着痛苦的迁移体验。

随着 Traefik v3 的推出，我们引入了一个简化的过渡流程，确保与 v2 语法的向后兼容性，同时提供了一个逐步采用 v3 语法的途径，有效地克服了之前迁移中遇到的挑战。

以下是我们遵循的指南：

显而易见的第一件事是提供一个详细的迁移指南，描述从 v2.x 迁移到 v3 时需要做出的每项变更。
静态配置中的重大变更是可以接受的，只要我们能在使用 v2.x 选项时提供用户友好的日志，并链接到新的 v3 格式。
动态配置将支持 v2.x 和 v3 配置格式。设想一个需要迁移 200 个入口资源的场景。您将能够不作任何改变地使用 Traefik v3，并且能够逐步将您的入口升级到新的格式。

总的来说，这应该对 Traefik 用户来说相当直接明了，以便采纳这个新的主版本，我们将仔细聆听您的反馈，以进一步改进迁移指南。

路由与安全

Traefik 的一个基本目的就是以安全和智能的方式路由网络流量。这是任何代理的核心部分，但 Traefik 一直是前沿的。这个 v3 版本也不负众望，带来了大量新功能和改进。

我们从 HTTP 开始，这是互联网的骨干。自 2015 年 HTTP/2 被批准以来，大量的工作已经投入到定义下一个里程碑：HTTP/3。这一点非常大，因为它不再依赖于过去可靠的 TCP，而是依赖 UDP（基于 QUIC，一种由 Google 在 2012 年开发的新传输协议）。

它带来了许多好处，如增强的性能、更快的连接建立、更简单的加密等。HTTP/3 现已从实验阶段退出，并在 Traefik 中完全准备好投入生产！感谢 Quic-Go 项目的维护者，特别是 Marten Seemann，感谢他们开发这个库并在推动这一进步方面所做的努力。

近年来，在云原生环境中广泛使用的一项关键技术是 gRPC。gRPC 是一个现代化的远程过程调用（RPC）框架，可以在任何环境中运行。它使用 Protocol Buffers 作为接口描述语言，并提供诸如双向流式处理、流量控制、取消和超时等高级功能。

Traefik v3 现在支持 gRPC-Web，这增加了在浏览器中从 Web 应用调用 gRPC 服务的能力。此外，Jeremy Jacque 为 Traefik 添加了 gRPC 健康检查支持。

在生产中部署数十或数百个服务会产生许多挑战。其中之一是让工作负载能够验证身份以相互信任。SPIFFE（即“为每个人提供的安全生产身份框架”项目）定义了一个框架和一套标准，用于识别和保护应用程序服务之间的通信。得益于 Julien Levesy，Traefik 现在支持通过其后端服务器的 SPIFFE mTLS！

Traefik 已经拥有非常强大的路由语法，但我们意识到某些部分可以进一步改进和统一，以使用户体验更加优化。

如果您需要在 Tailscale 网络内保护网站，Traefik 现在可以从 Tailscale API 请求 TLS 证书（通过 Let’s Encrypt 提供）！

Greg Linton 加入了期待已久的 Brotli 压缩算法支持，简言之意味着网站加载更快。Michael Kuhnt 带来了通过 PostgreSQL STARTTLS 的 SNI 路由。最后，您现在可以完全配置您的 TCP 服务器传输。

如您所见，完成的工作简直是疯狂的，它强化了 Traefik 作为开创性路由和安全功能的地位，同时坚持了流畅用户体验和顶级性能的原始优点。

增强版的 Traefik

回到 2019 年，随着 Traefik v2 的发布，我们引入了一个扩展引擎 Yaegi，它使得许多人能够为自己的上下文开发中间件（或提供者）。到今天为止，我们可以数出通过目录提供的一百多个中间件，还有更多是私有的。

Yaegi 是一个极其强大的引擎，其边界超越了 Traefik 本身。尽管如此，Yaegi 仍然需要大量的工作来支持完整的 Go 规范，并与语言的每个版本保持同步。这有时会导致添加非常具有挑战性的功能时遇到困难。

我们一直在关注的另一种扩展技术是 WebAssembly（Wasm）。直到今天，我们还没有对当前的 ABIs（应用程序二进制接口）如 proxy Wasm 感到满意，因为它们是为与其他技术紧密设计（Envoy）而设计的，这使得在我们的上下文中很难充分利用它们。

随着 http-wasm 的发布，它提供了一个标准的 ABI，旨在与 Go 内置的 HTTP 处理机制相匹配，游戏规则改变了。现在你可以利用 Wasm 来开发 traefik 的插件，消除了任何现有的障碍，并扩展了可能性的范围。

WebAssembly 支持：提升性能与安全性

WebAssembly（Wasm）是一种可在现代 Web 浏览器中运行的二进制代码格式。由于其高效性能和安全性，WebAssembly 在许多领域都得到了广泛应用。Traefik Proxy V3 引入了对 WebAssembly 的原生支持，这意味着开发者可以利用 Wasm 编写自定义的代理逻辑，进一步提升性能和安全性。

通过 WebAssembly，开发者可以编写高性能的代理模块，这些模块在运行时可以与 Traefik Proxy 紧密集成，从而提供更加精细的控制和优化。此外，由于 WebAssembly 的安全性特性，使用自定义代理模块可以进一步提高系统的安全性。

随时随地的全面可观察性

由于 Traefik 在您的架构中占据核心位置，为您做出关于请求路由的决策，自版本 1 以来，它已将可观察性作为其核心功能之一，支持多家供应商进行指标和追踪分析。

随着 OpenTelemetry 的出现，Traefik 自然会为采用铺平道路，并鼓励我们的用户迁移到最先进的工具。我们再次感谢 Jesse Haka 为此做出的贡献。

对于指标，Traefik 已经支持了广泛的供应商和广泛采用（如 Datadog、Prometheus 等），现在我们又增加了 OpenTelemetry，作为锦上添花：您可以在不损害已经建立的监控工具链的情况下，开始迁移到一个更新的堆栈。

关于追踪，情况则有所不同：Traefik 曾经是两个标准（OpenSensus 和 OpenTracing）的早期支持者，这两个标准现在已经合并为一个。采用率已经很高，迁移路径也很清晰。因此，我们放弃了之前标准，转而支持 OpenTelemetry。

但是，OpenTelemetry 并不是 Traefik 3 在可观察性方面的唯一亮点。对于 gRPC 爱好者，我们增加了对适当的健康检查的支持。一个简单的操作将会改变很多人的生活，至少在工作或实验室中是这样的。

而且我个人的最爱，与我们内心的极客对话，我们将日志记录系统改为零分配（意味着“性能更好”），结构友好，且具备轮换意识的日志记录器。这个小巧的调整将使整个理解系统、调试系统的过程变得更加容易。

Traefik 与 Kubernetes Gateway API 集成：统一控制平面

对于你们这些 Kubernetes 高手来说，你可能总是将 Traefik 视为你首选的入口控制器，并且你已经采用了 IngressRoutes 作为一种清晰的方式来摆脱古老 Ingress 规范的限制。这为许多好处打开了大门：例如声明式和更多路由选项这两个。

尽管 Kubernetes 在不断发展，Traefik 一直是 Gateway API 先锋的一部分，从支持首批 alpha 版本就开始了。我们现在正式带来全面支持的 Gateway API 规范，这并不令人意外。

Kubernetes 的力量也体现在其供应商生态系统中，允许 DevOps 选择最好的可用工具。在这方面，Traefik 一直是一个团队合作者，支持许多供应商、第三方编排器、可观察性组件和关键价值存储等。基于用户和客户的高度需求，我们很高兴地分享 Traefik v3 对 Hashicorp 的 Consul（用于需要特殊 TLS 管理的网格）和 Nomad（用于命名空间支持）有了更好的支持。

随着 Kubernetes 的普及，越来越多的企业选择使用 Kubernetes 来管理和部署微服务应用。为了更好地与 Kubernetes 集成，Traefik Proxy V3 引入了对 Kubernetes Gateway API 的支持。通过集成 Kubernetes Gateway API，Traefik Proxy 可以与 Kubernetes 集群中的其他组件无缝对接，实现统一的控制平面。

使用 Kubernetes Gateway API，开发者可以轻松地定义和管理微服务的网络路由、身份验证、授权等。这种集成方式使得 Traefik Proxy 可以更好地融入 Kubernetes 生态系统中，并为开发者提供更加便利的部署和管理体验。