Introduction

When a Traefik v2.2 IngressRoute example does not work, the issue is often one of four things: CRD not installed, wrong entryPoints, service/namespace mismatch, or router rule mismatch with actual request host/path. Since Traefik v2 uses CRDs and dynamic config, small manifest errors can silently produce no route.

A systematic debug process is faster than trial-and-error YAML edits.

Core Sections

1. Confirm CRDs and controller setup

Check that Traefik CRDs exist:

kubectl get crd | rg traefik

Ensure controller is running and watching target namespaces.

kubectl get pods -n traefik
kubectl logs -n traefik deploy/traefik

2. Validate IngressRoute manifest basics

1apiVersion: traefik.containo.us/v1alpha1
2kind: IngressRoute
3metadata:
4  name: app-route
5  namespace: default
6spec:
7  entryPoints:
8    - web
9  routes:
10    - match: Host(`example.local`) && PathPrefix(`/`)
11      kind: Rule
12      services:
13        - name: app-service
14          port: 80

Key checks:

• correct API version for installed Traefik
• correct entrypoint names (web, websecure, etc.)
• service name and port exist in same namespace unless explicitly cross-referenced

3. Verify request host header

Host-based routes require matching Host header.

curl -H "Host: example.local" http://<traefik-ip>/

Without host header, route may not match.

4. Test service backend independently

kubectl get svc app-service -n default
kubectl port-forward svc/app-service 8080:80 -n default
curl http://localhost:8080/

If backend fails directly, Traefik routing is not the root cause.

5. TLS and entrypoint alignment

If route uses TLS, ensure certificates and websecure entrypoint are configured. Mismatch between HTTP request and HTTPS-only route is a frequent issue.

Common Pitfalls

• Applying IngressRoute before CRDs are installed.
• Using wrong entryPoints names not defined in Traefik static config.
• Forgetting required host header for host-based rules during curl tests.
• Referencing non-existent service port or wrong namespace.
• Mixing HTTP and HTTPS route expectations without matching TLS config.

Summary

Traefik IngressRoute failures in v2.2 are usually configuration alignment issues, not mysterious runtime bugs. Verify CRDs, entrypoints, host/path matching, backend service health, and TLS settings in order. This structured approach quickly isolates the failing layer and makes route troubleshooting repeatable across environments.

A practical way to keep this guidance useful in real projects is to convert it into an executable runbook rather than leaving it as one-time reading. A strong runbook lists exact prerequisites, expected versions, environment assumptions, and a short sequence of checks that confirm healthy behavior. It also records the first one or two failure signatures engineers are most likely to see and maps each signature to the next diagnostic step. This structure reduces ambiguity when incidents happen under time pressure and helps new contributors act with the same consistency as experienced maintainers.

It also helps to keep one minimal reproducible fixture in version control for this exact scenario. The fixture can be a tiny script, API call, YAML manifest, query, or test harness that demonstrates both expected success and a known failure mode. When dependencies, frameworks, or infrastructure versions change, that fixture becomes an early warning system for regressions. Instead of discovering breakage deep in production workflows, teams can run a focused check in minutes and isolate whether the problem is environmental drift, configuration mismatch, or logic change.

For long-term reliability, add one lightweight automated guardrail to CI that targets the most fragile point in the workflow. Good candidates include schema validation, deterministic unit tests, protocol compatibility checks, API contract tests, and startup smoke tests. Keep the guardrail narrow and fast so it runs on every change and produces actionable output when it fails. If the same issue class appears repeatedly, promote the manual troubleshooting step into automation. Over time, this shifts effort from reactive debugging to preventive quality control, and ensures the article stays aligned with how teams actually build, test, and operate software.