# How to Create an IngressRoute With Multiple Paths

When working with **Traefik** as an ingress controller in Kubernetes, configuring an **IngressRoute** with multiple paths (or matches) is a common requirement. However, the official documentation doesn't always provide clear examples for this specific use case.

In this guide, I'll walk you through creating an **IngressRoute** with multiple paths and compare it with a standard **Kubernetes Ingress** for better understanding.

## Understanding the Traefik IngressRoute

Traefik uses [**IngressRoute** CRDs](https://doc.traefik.io/traefik/routing/providers/kubernetes-crd/) (Custom Resource Definitions) instead of the standard Kubernetes Ingress resource. This provides greater flexibility, allowing more advanced routing capabilities.

### Example: Traefik IngressRoute with Multiple Paths

Below is an example of an **IngressRoute** that routes traffic to different services based on the request path:

```yaml
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: my-ingressroute
  namespace: default
spec:
  entryPoints:
    - websecure # Change to "web" if using HTTP
  routes:
    - match: Host(`example.com`) && PathPrefix(`/api`)
      kind: Rule
      services:
        - name: api-service
          port: 80
    - match: Host(`example.com`) && PathPrefix(`/app`)
      kind: Rule
      services:
        - name: app-service
          port: 80
    - match: Host(`example.com`) && PathPrefix(`/auth`)
      kind: Rule
      services:
        - name: auth-service
          port: 80
```

### Breakdown:

- **entryPoints**: Specifies whether traffic is handled over HTTP (`web`) or HTTPS (`websecure`).
- **routes**: Defines multiple path-based rules for routing traffic to different services.
- **match conditions**: Each rule matches a combination of `Host` and `PathPrefix`, ensuring traffic is directed correctly.
- **services**: Each rule forwards traffic to a different backend service.

## Standard Kubernetes Ingress Example

If you are using the default Kubernetes **Ingress** instead of Traefik’s custom resource, you can achieve similar functionality like this:

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: traefik
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /app
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80
          - path: /auth
            pathType: Prefix
            backend:
              service:
                name: auth-service
                port:
                  number: 80
```

### Key Differences Between IngressRoute and Standard Ingress:

| Feature            | Traefik IngressRoute                                 | Standard Kubernetes Ingress       |
| ------------------ | ---------------------------------------------------- | --------------------------------- |
| Resource Type      | Custom Resource (CRD)                                | Built-in Kubernetes Resource      |
| Path Matching      | Uses `match` rules                                   | Uses `pathType` with Prefix/Exact |
| Middleware Support | Native and flexible                                  | Requires annotations              |
| Advanced Routing   | Supports weighted routing, retries, circuit breakers | Basic routing only                |

## Conclusion

If you're using **Traefik** as your ingress controller, **IngressRoute** provides greater flexibility and control over your routing rules. However, if you’re working in a more standard Kubernetes environment without CRDs, the built-in **Ingress** resource works just fine.

Both approaches allow you to efficiently route traffic based on URL paths, making it easy to manage multiple services under a single domain.