Path-Based vs Host-Based Routing in Ingress

Detailed Answer

Kubernetes Ingress supports two primary routing strategies: path-based and host-based. Understanding when and how to use each is essential for designing clean, scalable service routing.

Path-Based Routing

Path-based routing sends traffic to different Services based on the URL path:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-routing
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /dashboard(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: dashboard-service
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80

Traffic flow:

• myapp.example.com/api/users → api-service
• myapp.example.com/dashboard/metrics → dashboard-service
• myapp.example.com/anything-else → frontend-service

Host-Based Routing

Host-based routing uses the HTTP Host header (i.e., the domain name) to select the backend:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-app-routing
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
    - host: dashboard.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: dashboard-service
                port:
                  number: 80
    - host: web.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Each domain points to the same Ingress controller IP, and the controller routes based on the Host header.

Combined Routing

You can combine both strategies for complex architectures:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: combined-routing
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /v1
            pathType: Prefix
            backend:
              service:
                name: api-v1
                port:
                  number: 80
          - path: /v2
            pathType: Prefix
            backend:
              service:
                name: api-v2
                port:
                  number: 80
    - host: admin.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: admin-service
                port:
                  number: 80

This routes:

• api.example.com/v1/* → api-v1
• api.example.com/v2/* → api-v2
• admin.example.com/* → admin-service

Path Types Explained

| pathType | Behavior | Use Case | |---|---|---| | Prefix | Matches path prefix (element by element) | Most common | | Exact | Matches exact path only | Specific endpoints | | ImplementationSpecific | Controller decides matching | Regex-based paths |

Prefix matching rules:

• /api matches /api, /api/, /api/users
• /api does NOT match /apis or /api-v2 (element boundary)

Path Priority

When multiple paths overlap, the longest matching path takes priority:

paths:
  - path: /api/v1/users      # Highest priority for /api/v1/users
    pathType: Prefix
    backend:
      service:
        name: users-service
        port:
          number: 80
  - path: /api/v1             # Matches /api/v1/anything-else
    pathType: Prefix
    backend:
      service:
        name: api-v1-service
        port:
          number: 80
  - path: /                    # Catch-all
    pathType: Prefix
    backend:
      service:
        name: default-service
        port:
          number: 80

Choosing a Strategy

| Scenario | Recommended | |---|---| | Microservices sharing one domain | Path-based | | Separate applications with own domains | Host-based | | API versioning | Path-based (/v1, /v2) | | Multi-tenant SaaS | Host-based (tenant1.app.com, tenant2.app.com) | | Complex architecture | Combined |

Wildcard Hosts

Host-based routing supports wildcard DNS entries:

rules:
  - host: "*.example.com"
    http:
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: wildcard-service
              port:
                number: 80

This matches foo.example.com, bar.example.com, etc. — but not example.com or foo.bar.example.com.