Announcing Traefik Mesh 1.4 - New Name, New Features
Today, we're renaming the Maesh project to Traefik Mesh, and this corresponds with the renaming of the company behind the project to Traefik Labs. You can learn more about the company-wide rebranding effort here.
In addition to the renaming, Traefik Mesh 1.4 also brings some under-the-hood changes and new features, including support for a new version of the Service Mesh Interface (SMI) specification, enabling filtering by headers and more.
Renaming of the Project
As mentioned, the project is now called Traefik Mesh. The name change includes some changes in the project configuration as well. You'll notice that the annotation prefix, the binary name, the prefix for environment variables, and the configuration file's default name have all changed.
More importantly, we changed the DNS name to opt-in into the mesh usage from .maesh
to .traefik.mesh
. However, we made all of it backward compatible, so you should not encounter problems while transitioning from Maesh to Traefik Mesh. More information about the migration path is available in the documentation.
Going Back to Traefik ... to Traefik
For Maesh 1.3, we designed and implemented a custom proxy based on Traefik so we could evolve and iterate on the technology quickly. However, the capabilities we needed for this evolution have since all been introduced upstream into Traefik, allowing us to fall back to regular Traefik Proxy nodes for service communication. With this 1.4 release, Traefik Mesh now uses the standard Traefik image distribution as its service mesh proxy, which means Traefik Proxy features will be available to environments that use Traefik Mesh.
Header Filtering for Traffic Targets
With the release of SMI specification v0.5.0, filtering based on headers introduced in the Traffic Specs API v1alpha3 enables routing of requests based on arbitrary parameters such as browser types, and cookies. In addition to the headers, these are compatible with other filters, including request types (GET, PUT, etc.) and paths. By utilizing these new features, it's now possible to have additional flexibility when routing requests.
You can read more about this feature's capabilities and find examples in the SMI specification documents on Github.
Header and Path Filtering for Traffic Splits
The latest version of the spec empowers Traefik Mesh users to now run canary and A/B testing utilizing Headers, cookies, request type, and more. With the v1alpha3 release, Header filtering supports utilizing TrafficSplit and the matches attribute linked to an HTTPRouteGroup. A real world example is available in the SMI specification document, covering how this capability allows you to split traffic based on the aforementioned new filters.
Looking Ahead
The team is continuing work implementing mTLS, and the goal is to launch that feature with the next release. With the introduction of mTLS we anticipate some significant changes. We’ll be discussing those changes on Github and publishing a Release Candidate, which needs your feedback. In addition to mTLS, we are continuing to work with the SMI group by incorporating the latest version of the specification and contributing towards the implementation of routing UDP traffic. We expect to have that ready for the next release as well.
We love hearing from the community on how you’re using Traefik Mesh today in your environments and what features you’d like to see in the future. Let us know by opening a Feature Request or reaching out to us on our community forums.