Announcing Traefik 2.2 - With Enhanced Ingress support and more!

With Enhanced Ingress support and more!

After releasing 2.1 in December, we are excited to announce a new release. This one adds couple of long awaited features, but also brings simplicity in certain areas. Simplicity has always been a key feature of Traefik since the beginning and is utterly important for us, but also for you, our users. Our goal is to keep constantly improving the user experience by making the handling of Traefik even more easy, that you can focus on your real issues.

Enhanced Ingress Support

As announced with the 2.1 release, this release is focusing on user experience. For that reason, we brought back extended Ingress Support. Prior to Traefik v2.2, plain Kubernetes Ingress Objects were only supported without annotations. As our community told us, they have a valuable use-case where they want to run Traefik as a simple Ingress Controller, and don't want to fully commit to the IngressRoute in order to stay better included with the Kubernetes ecosystem. For that reason, we’re supporting Ingress Objects with a sub-set of annotations again.

kind: Ingress
  name: foo
  namespace: bar
  annotations: web, websecure [email protected] *
  - host:
      - path: /bar
          serviceName: service1
          servicePort: 80

Additionally, not all the behavior we want to be configurable for our users fit into the idea of an Ingress, therefore we're also supporting a subset of annotations on Service Objects to fill the gap.

apiVersion: v1
kind: Service
  name: service1
  namespace: bar
  annotations: "true"
  type: ClusterIP
  - port: 80
    name: http

A list of all annotations (Ingress and Service) can be found here

Entrypoint Redirection And Default Router Configuration

Traefik 2.x is really powerful, given the reworked architecture allowing us to operate from Layer 4 and above. Additionally, the new concept of routers, middlewares and services allows for more flexibility. As a result, you told us that the configuration ended up being a bit too verbose, and that you're missing some sort of redirects on Entrypoints, as we had something similar with Traefik 1.x.

For that reason, we introduced the concepts of Entrypoint redirects, and default router configuration.

With that release, it's possible to configure redirects bound to an Entrypoint through the static configuration. Additionally, you can also set defaults for the other areas a router can handle.

          to: foobar
          scheme: foobar
      - foobar
      - foobar
      options: foobar
      certResolver: foobar
        - main: foobar
          - foobar
          - foobar
        - main: foobar
          - foobar
          - foobar

Traefik will then create a default router, which will handle the configured redirects for you. For everything starting with middlewares, the default values will be copied automatically to all the routers you create.

Key Value Stores

Another long awaited feature have been the addition of Key Value Stores as a dynamic configuration provider in Traefik v2.Not only have former stores are re-added again (such as e.g. etcd or Consul), but new ones such as Redis have been added providing more supported platforms.


Support for TCP is one of the major changes from Traefik Version to Version 2. Now, with the new release we're also adding support for UDP! The only requirement is enabling an Entrypoint to be UDP based and that’s it.

    address = ":8093/udp"
    address = ":8093" # same as ":8093/tcp"

For now, we don't have any routing rules, as TLS is not supported currently (so there is no HostSNI), and there is no PathPrefix notion since there are no requests at the transport layer level. However, that’s not preventing you from load balancing your UDP services. That only means that you need to have one dedicated Entrypoint per UDP service you want to load balance.

Elastic APM Tracer

Elastic APM is a well known solution in the ecosystem. It's the APM solution provided by Elastic. Starting now, it's a supported Tracing backend for Traefik as well thanks to a community contribution. Just configure it, and you'll have your traces transferred to that system.

Web UI Enhancement

Last but not least, there have been a couple of modifications to the Web UI. Now not only will you be able to see your UDP services, but we’ve had a great community contribution to add a dark theme also!

What's next?

As we said with the previous release, focusing on improving the user experience is our goal. Implementing advanced Ingress support on Kubernetes and providing a way to configure defaults on an Entrypoint was one of our first steps. However, there are still things to be done which will be part of the upcoming release(s). Not only on improving the user experience but also on providing additional features. For that please keep raising your voice in the issue tracker, on the community forum, or better—pull request your way into making Traefik a better tool for everyone.

This is a companion discussion topic for the original entry at

What is the upgrade path (in production)?
From - Image: traefik:v2.1
Does the CRD get cut? Will settings be lost?
What are the commands.. this is already documented somewhere right?
:heart: Traefik - keen to upgrade.

Is the redirections documented yet? I can't quite work it out with foobar, foobar.

Thanks for the links Idez. For some reason, the info wasn’t where I expected it to find it.

Returning these two features to the static configuration has made a huge difference to our traefik v2 usability. We previously had to switch to having two layers of traefik routing in our production (and local development) stack, to match our multi-branch/multi-stack development cluster. Now we can return to an elegant solution where we only need a double layer to support multi stack routing and can have a more clean and efficient production stack.

Hey! WDYM?

It's a minor upgrade, so you can upgrade to 2.2. The CRD doesn't get cut, so you can still decide whether you want to use the CRD or Ingress. However, make sure that you have all CRD's (also the new ones) installed in your Cluster. See:

Ok.. Thank you! :grin:

Finally, I reverted all my ingress defintion to use native Ingress type. This is a welcome change.
Awesome job guys !!!

1 Like

Thanks for the feedback! Much appreciated.

Great. Does this mean we can upgrade straight from 1 to 2.2, with the only change being annotations (and of course the deployment)?

This might help...

I'm referring. to the ability to keep Ingress objects instead of upgrading to IngressRoute CRDs.