Blog
December 12, 2019

Traefik 2.1

2.X in the Wild

Releases keep coming, but this one feels unique to us because this is our very first release since Traefik 2.0, and we've learned a lot!

We all know it, you all know it: Traefik 2.0 consisted in a fest of new features: TCP, middleware, rule syntax, YAML support, CRDs, WebUI, canary, mirroring, provider namespaces, new documentation, and many other inconspicuous changes that will help us building the product we love towards greater heights.

All this was accompanied by tools to help the community seamlessly make the transition: We developed a migration tool,  launched a community forum to foster good communication and support, wrote new tutorials to help people have a fresh start with Traefik (including details about new TLS options), and of course we added a migration guide in our documentation.

Thanks to the (immense) feedback we got from the community, we know we can do even better, and we were given some pointers in the right direction.

But before we talk about what we've learned and how we'll leverage this knowledge, let's talk about the changes introduced in 2.1.

Consul Catalog Is Back!

Great news for Consul Catalog fans, Traefik 2.1 brings it back in the list of supported providers! (But stay on hold because I know for sure that others will follow suit.)

Improving the CRD

Stickiness

The stickiness option is the ability for a load balancer to keep using the same target for a client once it has been sent to one. This option is now available for our CRD users!

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: myName
  namespace: myNamespace
spec:
  entryPoints:
  - web
  routes:
  - kind: Rule
    match: Host(`some-domain`)
    services:
    - kind: Service
      name: myService
      namespace: myNamespace
      port: 80
      sticky:
        cookie: {} # Once a pod is selected for a client, it will stay the same for future calls

Service Load Balancing & Mirroring

Introduced in 2.0, service load balancing and mirroring were previously exclusively configurable using the file provider. With 2.1 and the introduction of the TraefikService object, we leveraged Traefik's CRD to enable such configuration in Kubernetes, and here is a first example with mirroring:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: my-route-to-mirroring
  namespace: default

spec:
  entryPoints:
    - web
  routes:
  - match: Host(`some-domain`) && PathPrefix(`/some/path`)
    kind: Rule
    services:
    - name: mirroring-example #targets the mirroring-example service
      namespace: default
      kind: TraefikService # we want to target the TraefikService we've declared (and not a K8S service named mirroring-example)
---
apiVersion: traefik.containo.us/v1alpha1
kind: TraefikService
metadata:
  name: mirroring-example
  namespace: default
spec:
  mirroring:
    name: v1 #sends 100% of the requests to the K8S service "v1" ...
    mirrors:
      - name: v2 # ... and sends a copy of 10% of the requests to v2
        percent: 10
        port: 80

For our second example, let's see how we could use service load balancing to do canary deployments:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: my-route-to-canary
  namespace: default
spec:
  entryPoints:
    - web
  routes:
  - match: Host(`some-domain`) && PathPrefix(`/some/path`)
    kind: Rule
    services:
    - name: mirror1
      namespace: default
      kind: TraefikService
---
apiVersion: traefik.containo.us/v1alpha1
kind: TraefikService
metadata:
  name: canary-example
  namespace: default

spec:
  weighted:
    services:
      - name: v1
        weight: 80
        port: 80
      - name: v2
        weight: 20
        port: 80

We can now change the weight for each service (v1 and v2) at will!

Mixing Regular (Kubernetes) Services with TraefikServices

When you define a target (with the name attribute) for your IngressRoute, by default, it targets a regular Service. If you want to target the new TraefikService objects, you just specify the kind attribute. What's great with this system is that you can chain and combine them at will, creating intricate patterns depending on your needs.

Below is an example that leverages both services and TraefikServices, and that uses mirroring and service load balancing at the same time!

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: route-to-mirroring
  namespace: default
spec:
  entryPoints:
    - web
  routes:
  - match: Host(`some-domain`) && PathPrefix(`/some/path`)
    kind: Rule
    services:
    - name: mirroring-example
      namespace: default
      kind: TraefikService
---
apiVersion: traefik.containo.us/v1alpha1
kind: TraefikService
metadata:
  name: mirroring-example
  namespace: default
spec:
  mirroring:
    name: canary-example
    kind: TraefikService
    mirrors:
      - name: service-mirror
        percent: 20
        port: 80
---
apiVersion: traefik.containo.us/v1alpha1
kind: TraefikService
metadata:
  name: canary-example
  namespace: default
spec:
  weighted:
    services:
      - name: v1
        port: 80
        weight: 80
      - name: v2
        weight: 20
        port: 80

Note on Updating the CRD for 2.1

While updating an installation to v2.1, it is required to apply the new CRD and to enhance the existing ClusterRoledefinition. You will find out how in the following guide.

More Control On Internal Routing

In 2.0, we've made changes to make sure people would be able to properly secure some critical services offered by Traefik, like the API and the Dashboard (you can see an example in our Traefik & Docker 101 article).

Pursuing the ability to configure internal services further while always giving users more control, the 2.1 dashboard now shows the internal routers and services involved.

Shows the internal services for the API and the Dashboard
Shows the internal routers leading to the internal API and Dashboard services (when users don't explicitly configure them)

We also jumped on the opportunity to add other configurable services to the list, namely rest@internal, ping@internal, and prometheus@internal.


Migrating to 2.X Made Easy

With so many new options to customize Traefik to your every need, we understand that some people can be a bit lost when migrating to 2.x, especially since Traefik is the kind of software that you run and forget (because it works nights and days without any other intervention from its users).

We have been working really hard to make this migration a matter of minutes.

So, if you're thinking about migrating but haven't jumped on the task yet, we want to point you in the right direction:

  • This guide helps you truly understand how Traefik 2 works on a Docker setup and will show you that 5 minutes are enough to have a good grasp of what you can do with it.
  • If you're looking for information about how to configure HTTPS / TLS, we have you covered with this guide!
  • If you don't want to lose time converting your Ingress objects in Kubernetes (who would want that?), we've developed a migration tool that will handle it for you.
  • Same goes with your traefik.toml file: the migration tool can convert it for you.
  • Oh, and the migration tool can also convert your acme.json certificate file.
  • And always feel free to engage conversation in our community forum, we read everything and do our best to provide answers when we can.

Supporting the 1.X Branch for Two Years!

Our community matters, and we don't want our users to feel rushed to migrate to version 2. We prefer seeing people slowly falling in love with the new tools Traefik has to offer and migrate. For this reason, we've decided to extend the support of the 1.X version until the end of 2021.

That's right: you have two years ahead of you before you need to make the leap! (And we believe you'll find benefits in migrating to 2.X way before that.)


Next? Focusing on the User Experience

In the introduction, we've stated that we received (and are still receiving) a lot of feedback about 2.0. And let me tell you:

We listen

Apart from bringing extra features in the next release (like UDP, HTTP/3, Key-Value Stores, and the list goes on ...), we want to focus this release on the user experience.

Now that we've seen people massively use Traefik 2, we decided it's time to work on making powerful features simpler to configure, or at least ... less verbose.

So, let's work together on making it happen! Come and raise your voice in the issue tracker, on the community forum, or better—pull request your way into making Traefik a better tool for everyone.

See you around, and happy Traefik!

About the Author

Latest from Traefik Labs

How Traefik Labs is Pioneering the Kubernetes Gateway API Revolution
Blog

How Traefik Labs is Pioneering the Kubernetes Gateway API Revolution

Read more
Traefik Proxy v3.2 - A Munster Release
Blog

Traefik Proxy v3.2 - A Munster Release

Read more
GitOps-Driven Runtime API Governance: The Secret Sauce for Scale
Webinar

GitOps-Driven Runtime API Governance: The Secret Sauce for Scale

Watch now

Traefik Labs uses cookies to improve your experience. By continuing to browse the site you are agreeing to our use of cookies. Find out more in the Cookie Policy.