Announcing Traefik Proxy 2.10
With improved native Kubernetes Service load balancing, new Prometheus metrics, new API group, and more.
There is always a lot of excitement around a new major version, but making the best possible Traefik Proxy 3.0 takes time and people. This past year, as we geared up to decide what Traefik proxy 3.0 should look like, we have also been working towards more open governance.
Our goal is to ensure the community can drive the direction of Traefik Proxy by influencing our roadmap and having significantly more input into feature design, implementation, and direct access via activities traditionally done by official maintainers, such as reviews. Check out these requests for design and input, as well as this hot topic on handling the migration to the new Kubernetes CRD definitions.
As part of our efforts to be more inclusive to our community, we have collected a series of small but mighty improvements that bring no breaking changes but enhance the user experience for many of our community members. Rather than holding these features until 3.0 is ready for release, we decided to ship these improvements early so that everyone can benefit from them right away.
Traefik Proxy 2.10 improves your ability to use service mesh with Traefik Proxy, enhances Prometheus metrics, and simplifies your Nomad configuration.
Let's jump into the new release and explore the nitty-gritty of your new abilities and how to use them.
Improved native Kubernetes Service load balancing
Up until now, Traefik Proxy only forwarded incoming traffic to pods. This made it difficult to address specific use cases that require the native Kubernetes load balancing with Traefik because it required the use of workarounds, for example, the creation of external services. These workarounds were unsatisfactory, and this missing feature was a blocker, especially for adopting Traefik for service mesh users.
Now, users have a new option for the providers Kubernetes Ingress and Kubernetes IngressRoute to decide whether the children of any given load balancer are directly in Pod IPs or if a Kubernetes Service is designated as the single child. In this case, the Kubernetes Service itself balances the load to the pods through a list of all endpoints used by the ingress controller in the upstream configuration.
This is especially important to users who employ a third-party service mesh, such as Cilium. Another benefit is that this configuration reinforces Traefik Proxy’s native support for zero-downtime deployments by removing any chance that traffic will be redirected to a non-existent client or pod (should a pod go down).
How it works
Enabling this feature is quite simple; all you need to do is add the `nativeLB` option to the service.
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: whoami
namespace: traefik
spec:
entryPoints:
- web
routes:
- kind: Rule
match: PathPrefix(`/who`)
services:
- kind: Service
name: whoami
namespace: app
port: 80
nativeLB: true # Enable the option
Note: In the specific case of a deleted pod, when a request comes in before Traefik has updated its routing configuration, you might generate a 502 bad gateway response because the Traefik configuration does not reflect the actual infrastructure. Using the `maxIdleConnectionPerHost` option mitigates the 502 error by creating a new connection with the backend service (pod), avoiding connection reuse to a pod that has suddenly gone down.
New Prometheus metrics
Prometheus is by far the most used third-party tool for metrics. To enhance the user experience when using Prometheus with Traefik Proxy, you can now split observations of the total request metric based on the value of one or multiple header values. This option allows you to gather more detailed information about your clients based on header information.
Headers are inherently flexible, so we can think of many ways you would use this feature, including creating a custom header to disclose app versions.
How it works
Traefik Proxy will now allow you to define extra labels for the `requests_total` metrics and the request header containing the value assigned to each label.
metrics:
prometheus:
buckets:
- 0.1
- 0.3
- 1.2
- 5.0
headerlabels:
useragent: "User-Agent"
Note: This feature is not enabled by default, therefore, there is no impact on performance by default. During testing, we did not observe any relevant performance hit. However, this does add an additional operation in the critical path of the request’s handling. When you enable the feature, if the header is not present in the request, it will be added automatically with an empty value. The label needs to be a valid label name for Prometheus.
Multiple namespaces in Nomad
Nomad allows you to use multiple namespaces within any given cluster. However, our original integration allowed you to use only a single namespace and required you to spin up an instance of Traefik Proxy per namespace within your cluster. We deprecated the singular namespace in the first Traefik Proxy 3.0 Beta, and this release brings the ability to use a single instance of Traefik to cover all namespaces within a given cluster.
providers:
nomad:
namespaces:
- "ns1"
- "ns2"
Introducing traefik.io API group
We are introducing our new CRD API group, `traefik.io`, with an eye to deprecating the `traefik.containo.us` API group in Traefik Proxy 3.0. Traefik Proxy v2.10 will bring no additional changes to the CRD scheme other than updating the API group. It will also include a warning log about the future depreciation of `traefik.containo.us` resources which will be removed in v3.0. You can read more about the community conversation in pull request 9600 and the Kubernetes CRD improvements in issue 9125. We would love to hear your feedback!
To use the new API group, install/update the CRDs and RBAC in your cluster, and you'll be able to define middlewares, IngressRoutes, etc., as either `traefik.containo.us` or `traefik.io`.
Wrapping up
We love that these features add flexibility to Traefik Proxy and hope you find them useful as well. We want to thank all the community members who have contributed to 2.10 through conversations on GitHub in issues and pull requests, donating code, testing, and sharing feedback on the 2.10 release candidate. This time, the special shout-out goes to Philipp and Sebastien, the top contributors of v2.10.
If you are interested in contributing to Traefik Proxy, join us on GitHub, where you can request features/enhancements, help us design the next version, or even get your hands dirty by creating or reviewing pull requests. For more information, check out the Release Notes and updated Docs. If you have questions, pop over to our Community Forum, where you can work with other community members to find your answers. And as always, we look forward to your feedback.
