Multi-Tenant Traffic Routing: How to Route Requests by Tenant in Kubernetes
In a multi-tenant system, the real problem is not choosing between Kubernetes Ingress and a load balancer. The real problem is deciding how a request for Tenant A reaches the right application, namespace, service, database boundary, and policy set without leaking traffic or creating operational chaos. Some teams route tenants by subdomain, some by path, some by header, and some by a dedicated load balancer or cluster for high-value tenants. Kubernetes Ingress, load balancers, and API gateways are tools in that routing design.
Implementation framework
Tenant Routing Decision Guide
Step 1
Start with tenant identity
Decide how the system identifies the tenant before routing.
Common choices are subdomain, custom domain, path prefix, request header, token claim, or a dedicated endpoint.
Subdomains such as tenant-a.example.com are usually easier to route at Ingress or gateway level than tenant identity hidden deep inside the application payload.
Step 2
Use subdomain routing for standard SaaS tenants
For most SaaS platforms, host-based routing through an Ingress controller is a clean default.
Requests like acme.example.com and globex.example.com can enter through the same cloud load balancer, reach the same Ingress controller, and then route to shared or tenant-specific services based on host rules.
Step 3
Use custom domains when customers need branded access
Enterprise tenants may want app.customer.com instead of customer.yourapp.com.
This usually requires DNS validation, certificate automation, host-based Ingress rules, and strong ownership of TLS renewal.
The load balancer exposes the entry point; Ingress or gateway handles domain-level routing.
Step 4
Use path-based routing only when the tenant model is simple
URLs like example.com/acme can work for internal tools or simple portals, but they become awkward with cookies, redirects, static assets, OAuth callbacks, and tenant isolation.
Prefer subdomains or custom domains when tenants need a clean boundary.
Step 5
Use header or token-based routing carefully
Tenant headers or JWT claims are useful behind an API gateway or service mesh, but they are easier to spoof if the trust boundary is unclear.
Only trust tenant headers when they are set by an authenticated edge component, not directly by public clients.
Step 7
Use dedicated load balancers for isolated or high-value tenants
Some tenants need private connectivity, strict network allowlists, regional isolation, dedicated capacity, or contractual separation.
In those cases, a dedicated LoadBalancer service, dedicated Ingress controller, or even a separate cluster can be easier to govern than complex shared rules.
Step 8
Use an API gateway for tenant-aware policy
If routing decisions depend on tenant plan, rate limits, authentication, quota, audit requirements, or request transformation, an API gateway is often the right edge component.
Kubernetes Ingress can still route traffic, but the gateway owns tenant-aware behavior.
Step 9
Design failure behavior explicitly
Decide what happens when a tenant route is missing, a certificate fails renewal, DNS points to the wrong edge, or a tenant-specific backend is unavailable.
Good multi-tenant routing includes safe defaults, clear 404 versus 403 behavior, tenant-aware logging, and fast rollback.
Step 10
Interview answer framing
Explain that tenant routing starts with tenant identification, then maps to routing strategy: subdomain or custom domain through Ingress for HTTP SaaS, LoadBalancer for dedicated or non-HTTP access, and API gateway for tenant-aware policy.
The strongest answer discusses security, cost, isolation, observability, and operational ownership.
Key principle 1
Mistake: Starting with Ingress versus LoadBalancer before defining tenant identity.
Why it matters
Why it fails: the routing layer cannot be correct if the tenant boundary is unclear. Better approach: first choose subdomain, custom domain, path, header, token claim, or dedicated endpoint.
Key principle 2
Mistake: Using path-based tenancy for complex SaaS products.
Why it matters
Why it fails: redirects, cookies, OAuth callbacks, and asset paths become fragile. Better approach: use subdomains or custom domains when tenants need a durable boundary.
Key principle 3
Mistake: Trusting tenant headers from public clients.
Why it matters
Why it fails: clients can spoof headers. Better approach: have the edge gateway derive tenant identity from authenticated domains, tokens, or validated configuration.
Key principle 4
Mistake: Creating a cloud load balancer for every tenant by default.
Why it matters
Why it fails: cost and operations scale poorly. Better approach: use shared Ingress for normal HTTP tenants and reserve dedicated load balancers for isolation requirements.
Key principle 5
Mistake: Forgetting certificate and DNS lifecycle.
Why it matters
Why it fails: tenant onboarding breaks when custom domains and TLS are manual. Better approach: automate DNS validation, certificate issuance, renewal, and route activation checks.
Key principle 6
Principle: Use shared Ingress for many HTTP tenants with host-based routing and common policies.
Key principle 7
Principle: Use dedicated LoadBalancer or dedicated Ingress when a tenant needs private networking, isolation, or custom edge controls.
Key principle 8
Principle: Use an API gateway when tenant-aware auth, rate limits, quotas, request shaping, or audit policy drive the routing decision.
Implementation Roadmap
Operational Review Questions
Question
How does the system identify the tenant: subdomain, custom domain, path, header, token claim, or dedicated endpoint?
Expected evidence
Mistake: Starting with Ingress versus LoadBalancer before defining tenant identity. Why it fails: the routing layer cannot be correct if the tenant boundary is unclear. Better approach: first choose subdomain, custom domain, path, header, token claim, or dedicated endpoint.
Question
Which tenants can share the same Ingress controller, and which tenants need dedicated edge infrastructure?
Expected evidence
Mistake: Using path-based tenancy for complex SaaS products. Why it fails: redirects, cookies, OAuth callbacks, and asset paths become fragile. Better approach: use subdomains or custom domains when tenants need a durable boundary.
Question
Where are tenant-specific TLS certificates, DNS records, and route rules created, validated, renewed, and rolled back?
Expected evidence
Mistake: Trusting tenant headers from public clients. Why it fails: clients can spoof headers. Better approach: have the edge gateway derive tenant identity from authenticated domains, tokens, or validated configuration.
Question
Which layer enforces tenant-specific authentication, rate limits, quotas, and audit logging?
Expected evidence
Mistake: Creating a cloud load balancer for every tenant by default. Why it fails: cost and operations scale poorly. Better approach: use shared Ingress for normal HTTP tenants and reserve dedicated load balancers for isolation requirements.
Question
What happens when a tenant route is missing, misconfigured, expired, or pointed to the wrong backend?
Expected evidence
Mistake: Forgetting certificate and DNS lifecycle. Why it fails: tenant onboarding breaks when custom domains and TLS are manual. Better approach: automate DNS validation, certificate issuance, renewal, and route activation checks.
Most teams route tenant traffic by subdomain or custom domain through an Ingress controller or API gateway. The route maps the tenant host to shared services, tenant-specific services, namespaces, or dedicated infrastructure.