Path-based routing in Kubernetes - Deep Dive

Overview - Path-based routing

What is it?

Path-based routing is a way to send web traffic to different backend services based on the URL path in the request. For example, requests to /images go to one service, while requests to /api go to another. This helps organize and manage traffic inside a Kubernetes cluster. It is often used with Ingress controllers to control how external users reach internal services.

Why it matters

Without path-based routing, all traffic would go to a single service or require separate ports or IPs for each service. This would make managing many services complicated and inefficient. Path-based routing allows multiple services to share one address and port, making it easier to scale, secure, and update applications. It improves user experience by directing requests quickly and correctly.

Where it fits

Before learning path-based routing, you should understand basic Kubernetes concepts like Pods, Services, and Ingress. After mastering path-based routing, you can explore advanced traffic management like load balancing, TLS termination, and canary deployments.

Mental Model

Core Idea

Path-based routing directs incoming requests to different services based on the URL path part of the request.

Think of it like...

Imagine a mailroom where letters are sorted by the street name on the envelope. Letters addressed to Elm Street go to one bin, while letters for Oak Street go to another. Similarly, path-based routing sorts web requests by their URL path and sends them to the right service.

Ingress Controller
  │
  ├─ /images ──▶ Image Service
  ├─ /api ─────▶ API Service
  └─ / ───────▶ Default Service

Build-Up - 7 Steps

1

Foundation

Understanding Kubernetes Services

Concept: Learn what a Kubernetes Service is and how it exposes Pods inside the cluster.

A Kubernetes Service groups a set of Pods and provides a stable IP and DNS name. It acts like a phone operator connecting callers to the right person. Services allow other parts of the cluster to find and talk to Pods without knowing their exact IP addresses.

Result

You can access a group of Pods through a single Service name or IP inside the cluster.

Understanding Services is key because path-based routing sends traffic to these Services, not directly to Pods.

2

Foundation

Basics of Kubernetes Ingress

Concept: Ingress is a Kubernetes resource that manages external access to Services, usually HTTP.

Ingress defines rules for routing external HTTP(S) traffic to Services inside the cluster. It uses an Ingress Controller to watch these rules and configure a load balancer or proxy. Without Ingress, you would need a separate external IP for each Service.

Result

You can expose multiple Services on one IP address and port using Ingress.

Ingress is the foundation for path-based routing because it controls how external requests reach Services.

3

Intermediate

Defining Path-based Rules in Ingress

🤔Before reading on: do you think path-based routing requires separate Ingress resources per path or can one Ingress handle multiple paths? Commit to your answer.

Concept: One Ingress resource can define multiple path rules to route traffic to different Services.

In an Ingress YAML, you specify rules with host and paths. Each path has a backend Service name and port. For example: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress spec: rules: - host: example.com http: paths: - path: /images pathType: Prefix backend: service: name: image-service port: number: 80 - path: /api pathType: Prefix backend: service: name: api-service port: number: 80

Result

Requests to example.com/images go to image-service, and requests to example.com/api go to api-service.

Knowing that one Ingress can handle multiple paths simplifies managing many routes and reduces resource overhead.

4

Intermediate

Path Matching Types and Their Effects

🤔Before reading on: do you think path matching is always exact or can it match prefixes? Commit to your answer.

Concept: Ingress supports different path matching types like Prefix and Exact, which affect how URLs are matched to paths.

The pathType field controls matching: - Prefix: matches if the request path starts with the specified path. - Exact: matches only if the request path exactly equals the specified path. For example, with Prefix /api, /api/users and /api/v1 both match. With Exact /api, only /api matches.

Result

You can control routing precision, allowing flexible or strict path matching.

Understanding path matching prevents routing errors and unexpected service hits.

5

Intermediate

Handling Default Backend and Overlapping Paths

Concept: Learn how Ingress handles requests that don't match any path and how overlapping paths are prioritized.

Ingress can specify a default backend Service for unmatched requests. When paths overlap, the longest matching prefix wins. For example, /api/v1 takes priority over /api if both exist. Example: - /api/v1 routes to api-v1-service - /api routes to api-service - default backend routes to default-service

Result

Requests to /api/v1/users go to api-v1-service, /api/help goes to api-service, and /unknown goes to default-service.

Knowing default backends and path priority helps avoid routing surprises and ensures all requests are handled.

6

Advanced

Using Annotations for Advanced Path Routing

🤔Before reading on: do you think path-based routing can be customized beyond basic rules using annotations? Commit to your answer.

Concept: Ingress controllers support annotations to customize routing behavior like rewrite, timeouts, or header manipulation.

Annotations are special key-value pairs added to Ingress metadata. For example, to rewrite /oldpath to /newpath: metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: /newpath This lets you change the request path before forwarding to the backend Service. Other annotations can control load balancing, SSL, or rate limiting.

Result

You can tailor routing behavior to complex application needs without changing backend code.

Understanding annotations unlocks powerful routing customizations essential for production environments.

7

Expert

Path-based Routing Performance and Security Implications

🤔Before reading on: do you think path-based routing adds significant latency or security risks by default? Commit to your answer.

Concept: Path-based routing affects request processing speed and security posture depending on configuration and controller implementation.

Each routing decision adds processing overhead in the Ingress controller or load balancer. Complex path rules or many rewrites can increase latency. Also, improper path rules can expose unintended services or allow path traversal attacks. Best practices include: - Minimizing complex regex or rewrite rules - Using strict pathType Exact when possible - Securing Ingress with TLS and authentication - Monitoring routing logs for anomalies

Result

Well-designed path-based routing balances performance and security, avoiding slowdowns or vulnerabilities.

Knowing the tradeoffs helps design scalable and secure routing in real-world Kubernetes clusters.

Under the Hood

When a request arrives at the Ingress controller, it inspects the HTTP Host header and the URL path. It compares the path against the configured rules in order, using the specified pathType (Prefix or Exact). Once a match is found, it forwards the request to the backend Service's cluster IP and port. The Ingress controller acts as a reverse proxy, managing connections and load balancing. It updates its routing table dynamically as Ingress resources change.

Why designed this way?

Path-based routing was designed to efficiently share a single IP and port among many services, reducing the need for multiple external IPs. Using URL paths for routing leverages the HTTP protocol's structure, making it easy to separate concerns by URL. The design balances flexibility with simplicity, allowing both broad and precise routing rules. Alternatives like port-based routing require more IPs and complicate firewall rules, so path-based routing became the preferred approach.

┌───────────────┐
│ External User │
└──────┬────────┘
       │ HTTP Request (Host + Path)
       ▼
┌─────────────────────┐
│  Ingress Controller  │
│ ┌─────────────────┐ │
│ │ Routing Rules   │ │
│ │ - Host: example.com │
│ │ - Paths: /api, /images │
│ └─────────────────┘ │
└───────┬─────────────┘
        │ Matches path
        ▼
┌───────────────┐   ┌───────────────┐
│ api-service   │   │ image-service │
│ (Cluster IP)  │   │ (Cluster IP)  │
└───────────────┘   └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does path-based routing require a unique IP per service? Commit yes or no.

Common Belief: Each backend service needs its own external IP address for routing.

Reality: Path-based routing allows multiple services to share a single IP by routing based on URL paths.

Why it matters: Believing this leads to unnecessary IP usage and complex network setups, wasting resources.

Quick: Does path-based routing always match exact paths? Commit yes or no.

Common Belief: Path-based routing only matches exact URL paths, so /api matches only /api.

Reality: Path-based routing supports prefix matching, so /api matches /api/users and /api/v1 as well.

Why it matters: Misunderstanding this causes routing errors where expected requests don't reach the right service.

Quick: Can path-based routing rewrite URLs by default? Commit yes or no.

Common Belief: Ingress path-based routing automatically rewrites the URL path before sending to backend.

Reality: URL rewriting requires explicit annotations; by default, the original path is forwarded unchanged.

Why it matters: Assuming automatic rewriting causes backend services to receive unexpected paths, breaking functionality.

Quick: Is path-based routing free from security risks? Commit yes or no.

Common Belief: Path-based routing is safe by default and does not introduce security concerns.

Reality: Improper path rules or missing TLS can expose services or allow attacks like path traversal.

Why it matters: Ignoring security risks can lead to data leaks or unauthorized access in production.

Expert Zone

1

Some Ingress controllers support regex path matching, but it can impact performance and complicate rule management.

2

The order of path rules matters; longest prefix matches first, so rule arrangement affects routing outcomes.

3

Annotations vary by Ingress controller; knowing your controller's supported annotations is critical for advanced routing.

When NOT to use

Path-based routing is not ideal when services require different ports or protocols other than HTTP/HTTPS. In such cases, use port-based Services or TCP/UDP LoadBalancers. Also, for very high traffic or complex routing, consider service meshes like Istio for more control.

Production Patterns

In production, teams use path-based routing to consolidate APIs and static content under one domain. They combine it with TLS termination, authentication, and rate limiting annotations. Canary deployments use path prefixes to route a subset of traffic to new versions. Monitoring and logging are integrated at the Ingress level to track routing behavior.

Connections

Load Balancing

Path-based routing builds on load balancing by directing traffic to different backends based on URL paths.

Understanding load balancing helps grasp how path-based routing distributes requests efficiently among services.

Reverse Proxy Servers

Ingress controllers act as reverse proxies that implement path-based routing rules.

Knowing reverse proxy concepts clarifies how requests are intercepted, inspected, and forwarded inside Kubernetes.

Postal Mail Sorting

Both involve sorting items (requests or letters) based on address parts to send them to correct destinations.

Recognizing this pattern across domains shows how routing logic is a universal problem solved similarly in different fields.

Common Pitfalls

#1 Using pathType Exact when prefix matching is needed.

Wrong approach:

paths:
- path: /api
pathType: Exact
backend:
service:
name: api-service
port:
number: 80

Correct approach:

paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80

Root cause:

Confusing Exact and Prefix path matching causes requests like /api/users to not match and fail routing.

#2 Not specifying a default backend, leaving unmatched requests unhandled.

Wrong approach:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: no-default
spec:
rules:
- host: example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80

Correct approach:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: with-default
spec:
defaultBackend:
service:
name: default-service
port:
number: 80
rules:
- host: example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80

Root cause:

Forgetting default backend means requests to unknown paths get no response or errors.

#3 Assuming Ingress rewrites paths automatically without annotations.

Wrong approach:

metadata:
name: rewrite-ingress
spec:
rules:
- http:
paths:
- path: /oldpath
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80

Correct approach:

metadata:
name: rewrite-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /newpath
spec:
rules:
- http:
paths:
- path: /oldpath
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80

Root cause:

Misunderstanding default behavior leads to backend receiving unexpected paths, breaking routing.

Key Takeaways

Path-based routing lets you send web requests to different services based on the URL path, all using one IP and port.

Ingress resources define these routing rules in Kubernetes, making external access to multiple services simple and efficient.

Understanding path matching types like Prefix and Exact is crucial to avoid routing mistakes.

Annotations extend routing capabilities, enabling URL rewriting and other advanced behaviors.

Proper design of path-based routing balances performance, security, and maintainability in production environments.