Traefik IngressRoute CRD: Kubernetes-Native Routing (2026)

The IngressRoute CRD in Traefik is not just another way to configure routing; it’s Traefik’s native way of understanding and expressing Kubernetes networking concepts, bypassing the older, more generic Kubernetes Ingress resource.

Let’s see it in action. Imagine you have a simple web service deployed in Kubernetes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
      - name: web
        image: traefik/whoami
        ports:
        - containerPort: 80

Now, to expose this service externally using Traefik and the IngressRoute CRD, you’d create something like this:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: my-web-app-route
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`myapp.example.com`) && PathPrefix(`/`)
      kind: Rule
      services:
        - name: my-web-app
          port: 80

This IngressRoute tells Traefik: "When a request comes in on the websecure entrypoint (typically HTTPS), if the Host header is myapp.example.com and the path starts with /, forward that request to the my-web-app service on port 80."

The core problem IngressRoute solves is the inflexibility and limited feature set of the standard Kubernetes Ingress resource. The Ingress API was designed to be generic, and as a result, it often lacks the specific capabilities needed for advanced routing scenarios. Traefik’s IngressRoute CRD provides a Kubernetes-native extension that allows you to leverage all of Traefik’s powerful routing features directly within your Kubernetes cluster. This includes things like precise path matching, header manipulation, TCP/UDP routing, and even integration with Traefik’s middleware for authentication, rate limiting, and more, all defined as custom resources.

Internally, Traefik watches for IngressRoute resources in your cluster. When it detects a new or updated IngressRoute, it parses the rules and configuration. It then dynamically updates its internal routing table to reflect these changes. This means you don’t need to restart Traefik for routing configurations to take effect; the changes are applied on the fly.

The key levers you control with IngressRoute are:

• entryPoints: These define which of Traefik’s listeners (e.g., web for HTTP, websecure for HTTPS) the route should apply to. You can specify multiple entrypoints.
• routes: This is an array of routing rules. Each rule has a match condition, a kind (usually Rule), and a list of services to forward traffic to.
• match: This is where the magic happens. You use Traefik’s expression language to define sophisticated matching logic. Examples include Host(\example.com`), PathPrefix(`/api`), Method(`POST`), Headers(`X-Custom-Header: some-value`), and combinations using logical operators like &&(AND) and||` (OR).
• services: This is a list of Kubernetes services that will receive the traffic if the match condition is met. You specify the service name and the port. Traefik will automatically discover the pods backing these services.
• middlewares: (Not shown in the basic example, but crucial for advanced use) You can attach Traefik middleware resources to an IngressRoute to add functionality like authentication, rate limiting, request modification, etc., before traffic reaches your service.

The IngressRoute CRD is designed to be granular. You can define multiple routes within a single IngressRoute object, each with its own matching logic and target services. This allows for complex routing scenarios, such as directing different paths of the same host to different backend services, or routing based on specific HTTP headers.

When you define a match rule like Host(\myapp.example.com`) && PathPrefix(`/api`), Traefik doesn't just look for an exact path match. It interprets PathPrefixas "any path that *starts with*/api". This allows a single rule to cover /api/users, /api/products, and so on, directing all of them to the specified service. This expression-based matching is far more powerful than the simple host and path matching found in the standard Kubernetes Ingress` resource.

One of the most powerful, yet often overlooked, aspects of Traefik’s IngressRoute is its ability to define TCP and UDP routes. While less common for typical web applications, this is critical for exposing services like databases or custom protocols. You would define a separate IngressRouteTCP or IngressRouteUDP CRD, specifying entryPoints for TCP/UDP and using different match rules (e.g., Port(5432)) to direct traffic to the appropriate Kubernetes service. This extends Traefik’s role from just an HTTP/S proxy to a full-fledged network traffic manager within your cluster.

The next step in mastering Traefik’s routing is understanding how to chain multiple IngressRoute resources together to build complex routing topologies.