Traefik is an open source reverse proxy and load-balancing tool that efficiently manages traffic to applications and microservices within cluster environments. It is natively cloud compliant and can be used with Kubernetes, Docker Swarm, and other orchestration system deployments.
Traefik is popular because it is easy to use and configure. The tool automatically listens for services and routing requests. This enables the autodiscovery of routing rules and dynamic updates, whether creating or deleting routes, in real time. Traefik is optimized for lightweight performance, ensuring it operates efficiently even in resource-constrained environments. With its own Kubernetes Custom Resource Definitions (CRDs) , Traefik offers the building blocks to extend and manage routing within your complex environments.
In this article, you'll explore how to deploy Traefik as an Ingress controller within your Kubernetes environment using official Helm charts .
Deploying Traefik Using Helm Before deploying Traefik, you'll need the following:
The following commands install the default Traefik configuration:
helm repo add traefik https://traefik.github.io/charts
helm repo update
kubectl create namespace traefik
helm install traefik traefik/traefik --namespace traefik
These commands add the official Helm repository to your environment. They then create a dedicated Kubernetes namespace for your Traefik deployment and execute Traefik within this namespace.
To set up your unique values and customize the installation, you can either edit the standard values.yaml
# ##Editing the standard template
helm pull traefik/traefik --untar
nano traefik/values.yaml
# ## Using your YAML
helm install -f myvalues.yaml traefik traefik/traefik
Configuring Traefik There are two configuration categories to note within Traefik: static and dynamic. The static configuration, also known as the startup configuration, deals with the connections to your providers and the specific EntryPoints Traefik should monitor. These elements won't change much as you scale. Your dynamic configurations in Traefik focus on how requests are handled and routed by the system. They may change as new routes and services are added. Traefik ensures these changes are implemented in real time without any request interruption or connection loss.
Let's dive into Traefik's configuration categories and how they are set up for your Helm chart deployment.
Static Configuration Traefik offers three mutually exclusive methods for defining your static configurations. You can utilize configuration files (YAML), command line arguments, or environment variables. On startup, Traefik will check for each of these methods in that order for your configuration values and set defaults if no values are found. Let's look at the values available within your static configuration and how they are set within the Traefik Helm chart.
EntryPoints EntryPoints are Traefik's network gateways, defining the ports and protocols (TCP or UDP) to listen for incoming traffic. You can use them to expose services and configure their specific access settings. If a service doesn't specify an EntryPoint, Traefik will use the default EntryPoint you've set.
Within the Helm chart, you can set EntryPoints under the ports section :
ports:
traefik:
…
web:
asDefault: true
port: 8000
expose:
default: true
exposedPort: 80
protocol: TCP
…
websecure:
port: 8443
# hostPort:
# containerPort:
expose:
default: true
exposedPort: 443
# targetPort:
protocol: TCP
…
streaming:
…
expose:
default: true
exposedPort: 1704
protocol: UDP
The above configuration defines three EntryPoints in your Helm chart: the TCP port 8000 exposed on port 80, another TCP port 8443 exposed on port 443, and the UDP port exposed on port 1704 within your Traefik deployment. The configuration also defines a default EntryPoint at port 8000, routing traffic through that EntryPoint unless otherwise specified.
Traefik offers a number of configuration options with your Entrypoints, allowing you to redirect requests, enforce secure access with TLS and proxies, and define custom behaviors for individual endpoints within your deployment.
Global Settings Your Traefik environment can include hundreds of resources running against different pods and services. While each resource can be configured individually for flexibility, Traefik also offers global settings to ensure compatibility between resources and alleviate resource management complexities. The Traefik Helm chart offers global arguments and shared labels to pass settings to all Traefik pods and ease management of all Helm-created resources:
commonLabels: {}
…
globalArguments :
- "--global.checknewversion"
- "--global.sendanonymoususage"
additionalArguments : []
The global arguments set your resources to periodically check if a new version has been released and send anonymous usage statistics. Utilize the commonLabels and additionalArguments sections to tag all your Traefik resources for management, and attach additional configuration, such as routing or security, to all your Traefik pods.
Environmental variables can also be passed into your deployments and declared within the Helm chart or from ConfigMaps and Kubernetes Secrets.
Providers Providers in Traefik are essential as they act as the link between your infrastructure and Traefik, providing routing and configuration details Traefik needs to manage traffic. Traefik relies on providers to automatically discover services and dynamically update the routing rules as things change. Depending on your environment, you use supported providers to query relevant routing information for your Traefik deployment. You can configure your Providers in the Helm chart .
Here's a Kubernetes CRD provider set up within the Helm chart to monitor all your Kubernetes namespaces for changes in routing and services:
providers:
kubernetesCRD:
# -- Load Kubernetes IngressRoute provider
enabled: true
# -- Allows IngressRoute to reference resources in namespace other than theirs
allowCrossNamespace: true
# -- Allows to reference ExternalName services in IngressRoute
allowExternalNameServices: false
# -- Allows to return 503 when there is no endpoints available
allowEmptyServices: true
# -- When the parameter is set, only resources containing an annotation with the same value are processed.
ingressClass: ""
# labelSelector: environment=production,method=traefik
# -- Array of namespaces to watch. If left empty, Traefik watches all namespaces.
namespaces: []
# -- Defines whether to use Native Kubernetes load-balancing mode by default.
nativeLBByDefault: false
Enabling and executing the Kubernetes IngressRoute provider also sets CRDs to provision your cluster. Kubernetes Ingress , Kubernetes Gateway , and file providers are also available through the Helm chart deployment.
TLS/SSL Configuration Most Traefik resources can be configured to use TLS for secure connections and routing. This is important to protect your sensitive data from exposure or interception between clients and your services. Secure access and connections may be a requirement in your use cases when you're working with sensitive and regulated data.
Within the static configuration, you can define certificate resolvers and integrate with an ACME provider (like Let's Encrypt ) to automate the generation and retrieval of security certificates. You can then use these generated certificates within your resources. Traefik uses the set dynamic configuration to obtain certificates based on the domains for which it's routing traffic. You can also use Traefik custom resources, such as TLS options and TLS stores , to dynamically set and store default and alternate security certificates for your resources.
The following YAML sets up a certificate resolver within your Helm chart and calls it for use within your TLS configurations:
certResolvers:
letsencrypt:
email: " {{ letsencrypt_email }} "
caServer: https://acme-v02.api.letsencrypt.org/directory
storage: /data/acme.json
…
tls:
enabled: true
certResolver: letsencrypt
Here, a Let's Encrypt account is added to the configuration with a set server directory and storage for generated certificates. The generated certificate can then be queried whenever a TLS connection is needed.
Traefik Dashboard The Traefik dashboard provides a visual interface to monitor your routing configuration and active routes. This feature can help you manage your Traefik deployment and observe its operations within your environment. It's disabled by default but can be enabled in your static configuration. It is recommended to either use your dashboard locally or secure access to the interface. Custom middleware aimed at authentication and allow-listing can be added to your dynamic configuration for the dashboard. You can also set match rules for your dashboard domain.
Here's an example of how to expose the Traefik dashboard within your environment while applying security measures to protect the connection with your Helm chart:
# Create an IngressRoute for the dashboard
ingressRoute:
dashboard:
enabled: true
# Custom match rule with host domain
matchRule: Host(`traefik-dashboard.example.com`)
entryPoints: [ "websecure" ]
# Add custom middlewares : authentication and redirection
middlewares:
- name: traefik-dashboard-auth
The dashboard will be accessible through the custom domain (traefik-dashboard.example.com) and served via the websecure EntryPoint. Additionally, an authentication middleware is applied to ensure only authorized users can access the dashboard.
Metrics and Monitoring Traefik offers a comprehensive metrics suite to deliver insights into your system's performance and usage. This is important for management and optimization, providing a holistic view of your environment's operations. The metrics are served by default in the OpenTelemetry format. You can also integrate metrics into your vendor-specific monitoring systems, with Traefik supporting Prometheus , Datadog , InfluxDB 2.X , and StatsD . You need to enable metrics tracking within your environment. The Helm chart defines a metrics endpoint that is not exposed by default.
Let's walk through enabling and configuring metrics in your Helm-based Traefik deployment:
metrics:
addInternals: true
## -- Prometheus is enabled by default.
prometheus:
## Enable metrics on routers. Default: false
addRoutersLabels: true
…
metrics:
port: 9100
expose:
default: true
exposedPort: 9100
protocol: TCP
In this configuration, metrics collection is turned on, with Prometheus enabled by default to provide visibility into your Traefik deployment. Additional labels are added for granular monitoring. The metrics are exposed on port 9100, allowing for easier integration with your monitoring systems.
Observability Traefik also offers other observability features , including logs for debugging operations and tracing to monitor the lifecycle of requests within your systems. Utilizing the full metrics, logs, and traces suite will help you gain complete visibility into your Traefik operations and speed up your optimization and debugging efforts.
Traefik's standard logs record events happening within your Traefik environment, while access logs record the traffic Traefik receives. By default, logs are written to stdout, leaving you to set a file path within your environment. Within the Helm chart, you need to enable access logs and tracing. Traefik uses OpenTelemetry collectors for distributed tracing.
Let's look at the associated logs and tracing variables within the Helm chart:
logs:
general:
filePath: "/path/to/traefik.log"
access:
# enable access logs, set storage path and size of log file
enabled: true
filePath: "/var/log/traefik/access.log
bufferingSize: 100
# allow internal observability
addInternals: true
…
tracing:
addInternals: true
otlp:
enabled: true
http:
# -- Set to true in order to send tracing metrics to the OpenTelemetry Collector using HTTP.
enabled: true
endpoint: #Default: http://localhost:4318/v1/metrics
Here, the logs' file paths are specified. Internal access logs are enabled with the preferred buffering size set for optimal performance. Tracing is also activated with OpenTelemetry, including an external endpoint for seamless integration and monitoring of request lifecycles.
These are the static configurations you will want to be enabled on startup within your Helm Traefik deployment, ensuring traffic routing, secure connections, and observability features.
Dynamic Configuration In Traefik, incoming requests first pass through EntryPoints, where they are routed based on defined rules and processed by any middleware that may modify the request or response. Once the requests are verified, they are forwarded to Services , which handle load balancing and route traffic to your applications and pods in the Kubernetes environment. The dynamic configuration — comprising routers, middleware, services, and the secure connection between them — is shaped by your infrastructure and environment, and it is dynamically discovered by providers within the Traefik setup, ensuring seamless integration with your architecture.
Let's look at setting up your dynamic configuration using Traefik's Helm chart.
IngressRoutes IngressRoutes are custom Kubernetes resources that extend Traefik's functionality by specifying how requests should be connected to services. The Helm chart explicitly defines two IngressRoutes for the Dashboard, as you already saw, and a health-check probe. This gives you a template for your basic routes.
Here's a sample IngressRoute embedded into the Helm chart to redirect requests:
ingressRoute:
httpToHttpsRedirect:
enabled: true
matchRule: PathPrefix(`/`)
services:
- name: noop@internal
kind: TraefikService
entryPoints: [ "web" ]
middlewares:
- name: redirect-to-https
…
extraObjects:
- apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: redirect-to-https
spec:
redirectScheme:
scheme: https
permanent: true
This IngressRoute redirects requests from the `web` endpoint to a more secure HTTPS domain. With the Helm chart, a match rule is set to control which requests will be redirected, and a middleware object is attached to perform the actual redirecting functionality.
For more complex routing behavior, it's recommended that you create and deploy your IngressRoute as a separate resource after your Traefik instance has been set up.
Here is a more complex IngressRoute sample that uses both path-based and host-based matching to route traffic to different services:
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
name: sampleingressroute
spec:
entryPoints:
- web
- websecure
routes:
- match: Host(`example.net`) && PathPrefix(`/bar`)
kind: Rule
priority: 12
# defining several services is possible and allowed, but for now the servers of
# all the services (for a given route) get merged altogether under the same
# load-balancing strategy.
services:
- name: s1
port: 80
# strategy defines the load balancing strategy between the servers. It defaults
# to Round Robin, and for now only Round Robin is supported anyway.
strategy: RoundRobin
- name: s2
port: 433
serversTransport: mytransport
- match: PathPrefix(`/misc`)
kind: Rule
services:
- name: s3
port: 80
middlewares:
- name: stripprefix
- name: addprefix
- match: PathPrefix(`/misc`)
kind: Rule
services:
- name: s3
# Optional, as it is the default value
kind: Service
port: 8443
# scheme allow to override the scheme for the service. (ex: https or h2c)
scheme: https
- match: PathPrefix(`/lb`)
kind: Rule
services:
- name: wrr1
kind: TraefikService
- match: PathPrefix(`/mirrored`)
kind: Rule
services:
- name: mirror1
kind: TraefikService
# use an empty tls object for TLS with Let's Encrypt
tls:
secretName: supersecret
options:
name: my-tls-option
namespace: default
In this configuration, traffic can come through both web (HTTP) and websecure (HTTPS) EntryPoints. Requests to example.net with the path /bar will be load balanced between two services (s1 and s2) using the round-robin strategy , while requests to /misc will be routed to service s3, with middleware applied to modify the request path. The final routes handle traffic for /lb and /mirrored, directing it to Traefik internal services for more advanced traffic management. Additionally, TLS is configured for secure communication.
Middleware Traefik middleware offers the flexibility to modify requests to fit specific use cases. Rather than using routes as they are, you can add additional features to enhance security, control access, and optimize operations. This customization allows you to implement functionalities such as authentication, rate limiting, or path rewriting, all without altering your application code.
There are official stores for TCP and HTTP middleware with a community gallery of third-party middleware . You can add in simple middleware, like redirects, as extraObjects in your Helm chart. You can then define the middleware in whichever resource you need to process requests through. You can also deploy middleware as a separate Kubernetes resource.
For example, if you are running a web service within your Kubernetes environment and want to manage traffic spikes, you can configure rate-limiting middleware within the Helm chart, ensuring the processing of requests is controlled to protect your services:
# Here, an average of 100 requests per second is allowed.
# In addition, a burst of 200 requests is allowed.
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: test-ratelimit
spec:
rateLimit:
average: 100
burst: 200
Services Services are the last component your incoming requests go through within the Traefik system. They are responsible for configuring how Traefik will reach your applications and eventually handle the incoming requests. Traefik offers a number of features within Services, allowing you to load balance and split traffic between application servers based on set priorities or weights. You can run multiple Traefik services within your cluster. For example, you could have an external-facing default service and another service only accessible internally by pods within the cluster.
Within the Helm chart, you can add Services under the additionalServices option:
service:
additionalServices:
internal:
type: ClusterIP
labels:
traefik-service-label: internal
Conclusion In this article, you explored deploying Traefik within Kubernetes using Helm, walking through the different configuration options available in Traefik, and how to set them within your Helm chart. Traefik is a flexible ingress control option that helps you implement complex and secure connections through your Kubernetes cluster.
mogenius is a cloud-agnostic platform offering self-service workspaces that simplify your Kubernetes deployments. With an intuitive UI and quick setup, you can install a preconfigured Traefik ingress controller within mogenius with just one click. This Traefik setup uses Helm under the hood and gives you best practice configuration with an easy customization process.
For more information about mogenius, check out our website or documentation .
.png)
