Learn Traefik - Kubernetes Service Mesh with Traefik Mesh

#Introduction

An ingress controller manages traffic entering the cluster. But what about traffic inside the cluster — between services? Episode 22 introduces Traefik Mesh, a product that goes beyond the ingress role toward a service mesh.

You should know from the start: Traefik Mesh has been retired by Traefik Labs and no longer receives active development. However, the concepts and standards it introduced — SMI, sidecar-free traffic splitting — are still very relevant, and understanding its architecture helps you evaluate modern service meshes. We study its design honestly, including its current status.

#Traefik Mesh Overview

#A Service Mesh Without Sidecars

Traefik Mesh is a lightweight, non-invasive SMI-based service mesh (Service Mesh Interface): no sidecar proxy is injected into every pod. Instead, inter-service traffic passes through the existing Traefik edge, with SMI CRDs as the control plane.

This difference in approach is significant:

• No sidecars: application pods stay clean; no extra resource overhead per pod.
• Centralized: all traffic policies are managed from a single point — Traefik itself.
• SMI-compatible: TrafficSplit, TrafficTarget, and other resources follow the SMI standard.

The consequence: Traefik Mesh makes the most sense for small-to-medium clusters that want traffic management without the complexity of heavy service meshes like Istio.

#Main Features

#Traffic Management

• Traffic splitting: divides traffic between service versions.
• Circuit breaking: cuts the flow when the error ratio crosses a threshold.
• Retry policies: automatic retries for transient failures.
• Rate limiting: limits requests per source.
• Access control: communication permission policies between services.

#Observability

Like Traefik Proxy, all traffic decisions can be monitored: metrics, logs, and tracing are available from the central point, without having to change application code.

#Architecture in the Cluster

Conceptually, Traefik Mesh sits at the cluster edge and manages inter-service traffic without touching application pods:

incoming traffic
    |
Traefik Proxy (edge router + mesh controller)
    |               |
service A       service B

The control plane reads SMI resources such as TrafficSplit and TrafficTarget, then translates them into Traefik configuration. The data plane still runs on Traefik itself — no new proxy is injected into every pod.

#Installation

#Helm Chart

Traefik Mesh is installed via Helm, usually alongside Traefik Proxy. Start with helm repo add then upgrade the chart:

helm repo add traefik-mesh https://traefik.github.io/traefik-helm-chart
helm upgrade --install traefik-mesh traefik-mesh/traefik-mesh \
  --namespace traefik-mesh --create-namespace

This process deploys a mesh controller that reads SMI resources and translates them into Traefik configuration. Because there are no sidecars, there is no proxy injector to configure in application namespaces — one of the reasons this mesh was popular in its early days. Verify with kubectl get pods in the traefik-mesh namespace to confirm the controller is running.

#Traffic Management with TrafficSplit

#The TrafficSplit Resource

The heart of SMI traffic management is the TrafficSplit resource — exactly like the weighted services you know:

apiVersion: split.smi-spec.io/v1alpha4
kind: TrafficSplit
metadata:
  name: app-split
  namespace: default
spec:
  service: app-service
  backends:
    - service: app-v1
      weight: 900
    - service: app-v2
      weight: 100

The resource above directs 90 percent of the app-service traffic to app-v1 and 10 percent to app-v2. Weights are written on a base of a thousand.

#Advanced Deployment Patterns

• Canary: start at 99/1, gradually raise the new version's weight while monitoring error rates.
• A/B testing: besides weights, combine with header rules so a group of users is directed to the new version.
• Blue/green: 100/0 on one version, then suddenly flip to 100/0 on the other version when ready.

All changes are done via kubectl apply — the mesh controller applies them to Traefik without restarts.

#Closing

Key takeaways:

• Traefik Mesh is a non-invasive, sidecar-free SMI service mesh.
• Features: traffic splitting, circuit breaking, retry, rate limiting, access control.
• Installation via Helm with a mesh controller as the control plane.
• TrafficSplit divides traffic with weights on a base of a thousand.
• Canary, A/B, and blue-green patterns are expressed through SMI resources.
• Traefik Mesh is retired: learn the concepts, not the deployment.

In episode 23 next we enter the observability phase: metrics & Prometheus — enabling the /metrics endpoint, the counter, gauge, and histogram metric types, important metrics per entrypoint, router, and service, Prometheus scrape configuration, and Grafana dashboards and PromQL queries for alerting.