DEV Community

Anh Trần Tuấn
Anh Trần Tuấn

Posted on • Originally published at tuanh.net on

Path-Based Routing with Kubernetes Ingress: Best Practices and Techniques

1. Understanding Kubernetes Ingress and Path-Based Routing

Kubernetes Ingress is a resource that manages external access to services within a Kubernetes cluster, typically through HTTP or HTTPS. Ingress facilitates routing decisions based on hostnames and URL paths, which means you can control where traffic should go within your cluster based on the path of the request.

1.1 Why Path-Based Routing?

Path-based routing allows Kubernetes clusters to split traffic across multiple services depending on the request path. This approach is ideal when managing microservices because each service can independently handle a subset of the application’s URLs.

For example, in an e-commerce application, /products might route to the product service, while /users goes to the user service.

1.2 Ingress Controllers: The Backbone of Routing

To make path-based routing effective, you need an Ingress controller, which is a Kubernetes component responsible for fulfilling the Ingress rules. Popular Ingress controllers include NGINX, Traefik, and HAProxy. These controllers interpret the Ingress resources and route the traffic accordingly.

1.3 Basic Structure of an Ingress Resource

An Ingress resource defines rules that dictate how requests are routed. Let’s look at a minimal Ingress example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /products
        pathType: Prefix
        backend:
          service:
            name: product-service
            port:
              number: 80
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 80
Enter fullscreen mode Exit fullscreen mode

In this setup:

  • Requests to myapp.example.com/products route to the product-service.
  • Requests to myapp.example.com/users route to the user-service.

2. Best Practices for Path-Based Routing with Kubernetes Ingress

For a reliable and optimized setup, applying best practices is crucial.

2.1 Use Specific Path Types

In Kubernetes Ingress, there are three main pathType options: Exact, Prefix, and ImplementationSpecific. Choosing the appropriate type for each path is critical:

  • Exact : Matches the full path exactly, which is useful for well-defined routes.
  • Prefix : Matches based on a path prefix. For example, /api matches both /api/products and /api/users.
  • ImplementationSpecific : This depends on the controller being used and may vary in behavior.

Choosing the correct pathType ensures that routing behavior is predictable and aligns with your application’s needs.

2.2 Avoid Overlapping Paths

Overlapping paths can cause routing conflicts, where multiple services match the same path prefix. A best practice is to design path structures that are unique across your services.

For instance, avoid defining /api for one service and /api/users for another within the same Ingress resource. Instead, structure paths clearly to prevent ambiguity.

2.3 Secure Traffic with TLS

Securing traffic using TLS termination at the Ingress level protects the data and boosts user confidence. By adding TLS configuration to your Ingress, the communication between clients and services becomes encrypted.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
spec:
  tls:
  - hosts:
      - myapp.example.com
    secretName: tls-secret
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /products
        pathType: Prefix
        backend:
          service:
            name: product-service
            port:
              number: 80
Enter fullscreen mode Exit fullscreen mode

This setup requires a valid TLS secret (tls-secret) in the same namespace, which stores the certificate and private key.

2.4 Limit the Number of Ingress Resources

Creating multiple Ingress resources within the same namespace may lead to complex routing configurations and increased risk of conflicts. For simpler management, group related paths within a single Ingress resource.

2.5 Monitoring and Logging

Path-based routing setups often span many services. Therefore, monitoring and logging are essential for understanding traffic patterns and troubleshooting issues. Configure logging within your Ingress controller to record request paths, response times, and any errors.

2.6 Use Host-Based Routing for Multi-Tenant Environments

If you manage multiple tenants within a single cluster, combining host-based and path-based routing is a best practice. Each tenant can have their subdomain, and specific paths within each subdomain can route to designated services.

For example:

  • tenant1.example.com/products routes to product-service-tenant1
  • tenant2.example.com/products routes to product-service-tenant2

3. Advanced Configuration Options

3.1 Path Rewrites

Some applications require URL path rewrites. With NGINX Ingress, for example, you can rewrite paths to simplify backend URLs:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: store-service
            port:
              number: 80
Enter fullscreen mode Exit fullscreen mode

In this configuration, requests to /store rewrite to / before reaching the store-service. This approach can mask backend paths, creating cleaner URLs for users.

3.2 Rate Limiting and IP Whitelisting

Traffic control is a crucial aspect of routing. In scenarios where certain paths are more sensitive (e.g., /admin routes), consider using rate-limiting or IP whitelisting through Ingress controller annotations:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/limit-connections: "10"
    nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.0.0/24"
Enter fullscreen mode Exit fullscreen mode

This configuration limits connections to 10 and allows only requests from specified IP ranges.

4. Conclusion

Path-based routing in Kubernetes Ingress opens numerous opportunities for routing traffic within a Kubernetes cluster efficiently and securely. Following best practices—from selecting the appropriate path types and securing with TLS to logging and monitoring—ensures that your application routing remains robust, scalable, and easy to maintain.

If you have any questions or need further assistance with Kubernetes Ingress or other Kubernetes-related topics, please leave a comment below.

Read posts more at : Path-Based Routing with Kubernetes Ingress: Best Practices and Techniques

Top comments (0)