Traefik 3.0 Works Better With WebAssembly and OpenTelemetry
VIENNA — Traefik Proxy 3.0’s creators and contributors are finalizing some of the more promising aspects of the wildly popular reverse proxy and load-balancing software. This includes OpenTelemetry integration and WebAssembly (Wasm) support for Wasm plugins, both of which significantly enhance Traefik’s functionality.
Additionally, Traefik Proxy’s support for the Kubernetes Gateway API is seeing improvements as a third major component of the latest version of Traefik. These enhancements significantly improve latency and other metrics, thanks to some modifications in its integration with the API.
During his talk, aptly titled “Deep Dive Into Traefik 3.0,” Traefik Labs CTO and Traefik Proxy creator Emile Vauge described the Open Source Summit keynote here, what this all means for users — a lot, if you want improved observability and more.
For WebAssembly, the improved latency aspect is a key characteristic for reverse proxy functionalities. This includes how the Wasm plugin, now available, or the integration and adaptability of Wasm plugins, offers ways to boost or improve the latency of Traefik calls. This improvement is largely due to the lightweight nature and speed of WebAssembly. WebAssembly offers security functionality through what’s called a sandbox of modules, which poses difficulties for interception, and this now extends to Traefik.
OpenTelemetry now pulls together different data sources and consolidates them into a single format, encompassing traces, metrics, and soon, logs. Although still being finalized, OpenTelemetry instrumentation-provided logs are expected to be available in the coming weeks.
Traefik Proxy 3.0’s support for the Gateway API should help solve many ingress headaches for Kubernetes routing control and management.
@traefik can offer a lot more with @opentelemetry, #wasm, and API Gateway support. CTO Emile Vauge dove in at #OSS during his talk Deep Dive Into Traefik 3.0. @linuxfoundation @thenewstack pic.twitter.com/Y8m6giVOgF
— BC Gain (@bcamerongain) September 17, 2024
Since the first commit in 2015, Traefik has been designed to be lightweight, written in Go, self-contained in one binary, and “extremely fast,” Vauge said. “It’s incredibly simple, yet it provides access to very advanced features. However, the user experience remains extremely straightforward,” Vauge said. “That, I would say, is the philosophy behind the project I had in mind.”
There are plenty of metrics that probably portend even more downloads, contributions, forks, etc., thanks to these improvements. Already, Traefik Proxy has been downloaded 3.3 billion times, is in the top 15 most downloaded images on GitHub, and is one of the most popular projects on Docker.
“The metric I love the most is the number of contributors. To me, it’s the best indicator of how healthy a project is. It shows that this isn’t just a project built by a company — it’s a project built by a community,” Vauge said during his talk. “The number of contributors is still growing at an incredible pace, and that’s the best sign of success.”
Wasm Plugin Rules
During the Open Source Summit, Vauge described how Traefik Proxy 3.0 allows users to “build and use any Wasm plugin.” You can customize the reverse proxy pipeline with your own plugin, for example, to interact with a web application firewall — “but it can be anything,” Vauge said. “If you want to build your own authentication mechanism, you can plug it into the traffic pipeline, and it will operate.”
Traefik Proxy 3.0 was designed to offer more push for observability, especially with OpenTelemetry. This includes, of course, monitoring all traffic requests and then sending them to the observability backend of your choice. “You can send OpenTelemetry data to any component, as it acts as a bottleneck point, meaning it sees everything in your infrastructure,” Vauge explained.
This OTel aspect is especially interesting because the reverse proxy can send telemetry and observability data “anywhere,” Vauge said. “It’s not replacing Grafana or other alternatives but is integrating with them by using the OpenTelemetry format. The fact that it uses OpenTelemetry means you can switch tools easily. You can use Grafana, or you can use something else.”
As OpenTelemetry instrumentalizes and standardizes tracing, logging, and metrics, the idea with Traefik v3 is that it has integrated the latest version of OpenTelemetry. This means “we can now handle metrics endpoints as a modern standard and tracing as a local standard, which is excellent,” Vauge said. However, as mentioned above, logging through OpenTelemetry with Traefik remains a work in progress. The Go SDK is still in beta, and the latest OpenTelemetry specification is relatively new. “The ecosystem isn’t fully ready yet, but we’re constantly tracking the logging implementation,” Vauge said. “Once Traefik is out of beta, we’ll integrate it and complete the setup. In the meantime, you can still export logs in the usual way, as we’re all accustomed to.”
Indeed, OpenTelemetry represents a major development in the microservices world and a “big step forward,” Vauge said. “It helps avoid the need for dozens of different observability and tooling implementations. If you’re building something from scratch, keep in mind that OpenTelemetry is the future, and it’s already here today.”
Big Step Forward
The Gateway API, which is also a “big step forward,” Vauge said, builds upon the Ingress support Traefik has offered since 2015. Until recently, Ingress was the default way to expose services on Kubernetes, which Traefik supported since Ingress’ creation.
“The good thing about Ingress is that it’s simple. The downside, however, is that it’s too simple — you can’t do much beyond basic API exposure,” Vauge said. “When you need to add more advanced security mechanisms or other features, you quickly run into limitations. This has led to reliance on annotations that are vendor-specific and tied to individual controllers, undermining the initial goal of vendor neutrality. Additionally, Ingress is limited to HTTP, which is fine, but insufficient for services that use TCP or UDP. That’s why it has been deprecated.”
The Gateway API specification was designed for both operations teams and developers. As Vauge described, operations teams can manage the GatewayClass and the Gateway. The GatewayClass defines the gateway controller that is used in your Kubernetes cluster. For example, Traefik can act as a GatewayClass, which serves as the entry point for your ingress controller, “listening” for incoming requests, Vauge said.
“Ops teams can do much more than that — they can predefine HTTP routes and apply constraints,” Vauge said. “On the other hand, developers typically just want to expose their applications without worrying about the underlying ports and other configurations.”
