Note about Traefik static and dynamic configuration on Kubenetes using Helm chart, ConfigMap and CRD
Background
After quite a while on configuring Traefik as ingress controller in Kubernetes, I feel there are need to share some ideas regarding some confusions I have been through on different configurations and my current operation approach on how those being configured.
This article aimed to describe:
- Static and Dynamic configuration
- Different deployment approaches (a. Helm chart / b. Command Line Interface [CLI] / c. File base [through ConfigMap] / d. Environment variables / e. Custom Resources Definition [CRD] )
- My current choices
Static and Dynamic Configuration
The official documentation does have sections mentioned about this (which I didn’t read at the beginning of my journey, which is a big mistake)
Summary as:
Different deployment approaches
Helm chart
I like using helm chart to deploy Traefik, it is likely the simplest approach to install Traefik into Kubernetes cluster. The official Traefik documentation stated the steps how to install through helm.
What Helm chart achieve is like a setup template that allow some customization through a config file, the detail configs can always be referred in values.yaml of the chart (see github link to Traefik offical helm chart values.yaml)
The configuration cover only static configurations (there are section of entrypoint, differnet sections for global options, as well as adding CLI config on additionalArguments section).
Because Helm chart deployment is expected to redeploy the services / pods, so we expected there is downtime on the Traefik pod.
Common Line Interface (CLI)
When we check Traefik document, we would see most commonly there are 3 reference ( File(YAML), File(TOML) and CLI )
CLI cover both static and (some) dynamic configurations, as I see examples from internet, it’s mainly applied to docker as start command. I never used this approach.
File base (through ConfigMap )
Cover both static and dynamic configurations, I believe this is the most versatile approach, and likely there would be most example out there on the internet
The way we make it work is define a ConfigMap in Kubernetes:
Then we bind it to the Traefik deployment’s volume (example below is config file of Helm chart):
Note that config map update would require the pod reload, so I normally only put static config.
Environment Variable
This is new to me, I know this only because I am preparing this article, I think it could be of good use. Reference link.
Note that environment variable only cover static configurations.
Custom Resource Definition (CRD)
This is the most Kubernetes approach, because Traefik created the CRD for Kubernetes, I mainly use IngressRoute (incuding variant of TCP/UDP) and Middleware.
The CRD approach only cover dynamic configurations.
Summary
My preference (at the moment)
I would use Helm chart for static configurations, given static configuration would take effect on process restart, so Helm chart deployment does no more harm than other approaches, and in addition, I can enjoy the version rollback.
For dynamic configurations, I prefer to use CRD as it’s more Kubernetes-ly and I use a set of yaml files together with Kustomize to manage different environments.
