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 ClusterRole
definition. 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.
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!