What if you could run many websites on one server without messy setups or wasted resources?
Why Host-based routing in Kubernetes? - Purpose & Use Cases
Imagine you run a website that serves different content for different domains, like shop.example.com and blog.example.com. Without host-based routing, you must manually configure separate servers or IP addresses for each domain.
This manual setup is slow and error-prone. You have to manage multiple servers or IPs, update DNS records, and handle traffic routing yourself. It's easy to misroute users or waste resources by running many servers.
Host-based routing lets you use one server or load balancer to direct traffic based on the website address users enter. Kubernetes Ingress can automatically send requests to the right service depending on the host name, simplifying management and saving resources.
server {
listen 80;
server_name shop.example.com;
location / {
proxy_pass http://shop-service;
}
}
server {
listen 80;
server_name blog.example.com;
location / {
proxy_pass http://blog-service;
}
}apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
spec:
rules:
- host: shop.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: shop-service
port:
number: 80
- host: blog.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: blog-service
port:
number: 80
Host-based routing enables you to run multiple websites on a single Kubernetes cluster with simple, centralized traffic control.
A company hosts its marketing site, customer portal, and blog on the same Kubernetes cluster. Using host-based routing, all traffic is routed correctly without needing separate servers or IPs.
Manual routing requires multiple servers and complex setup.
Host-based routing directs traffic by domain name automatically.
Kubernetes Ingress makes managing multiple sites easy and efficient.
Practice
Solution
Step 1: Understand host-based routing concept
Host-based routing directs requests to services depending on the host name in the URL.Step 2: Compare options to the concept
Only To send traffic to different services based on the website address (host). matches this behavior; others describe different features.Final Answer:
To send traffic to different services based on the website address (host). -> Option DQuick Check:
Host-based routing = directing traffic by host [OK]
- Confusing host-based routing with load balancing
- Thinking it encrypts traffic automatically
- Assuming it monitors service health
Solution
Step 1: Review Kubernetes Ingress host-based routing syntax
The correct syntax uses 'rules' with 'host' and 'http.paths' specifying backend service details.Step 2: Match options to correct syntax
spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service port: number: 80 matches the official Kubernetes Ingress spec format for host-based routing.Final Answer:
spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service port: number: 80 -> Option BQuick Check:
Correct Ingress host syntax = spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service port: number: 80 [OK]
- Placing 'host' under metadata instead of rules
- Using deprecated 'serviceName' and 'servicePort' keys
- Confusing 'path' with 'host' field
spec:
rules:
- host: app.example.com
http:
paths:
- path: /app
pathType: Prefix
backend:
service:
name: app-service
port:
number: 8080
- path: /
pathType: Prefix
backend:
service:
name: default-service
port:
number: 80Solution
Step 1: Analyze the Ingress rules for host 'app.example.com'
The rule for host 'app.example.com' has two paths: '/app' and '/'.Step 2: Understand path matching priority
Requests with path starting '/app' go to 'app-service' on port 8080; all other paths go to 'default-service' on port 80.Final Answer:
Traffic to app.example.com with path starting /app goes to app-service; others go to default-service. -> Option AQuick Check:
Host + path routing = Traffic to app.example.com with path starting /app goes to app-service; others go to default-service. [OK]
- Assuming all traffic goes to first service listed
- Thinking duplicate hosts cause rejection
- Ignoring path prefixes in routing
spec:
rules:
- host: shop.example.com
http:
paths:
- path: /shop
backend:
serviceName: shop-service
servicePort: 80Solution
Step 1: Check Ingress backend service syntax
Modern Kubernetes Ingress requires 'service.name' and 'service.port.number' keys, not 'serviceName' and 'servicePort'.Step 2: Identify the error in YAML
The YAML uses deprecated keys causing routing failure.Final Answer:
The keys 'serviceName' and 'servicePort' are deprecated; use 'service.name' and 'service.port.number'. -> Option AQuick Check:
Use correct backend service keys = The keys 'serviceName' and 'servicePort' are deprecated; use 'service.name' and 'service.port.number'. [OK]
- Using old 'serviceName' and 'servicePort' keys
- Adding host under metadata instead of rules
- Changing path unnecessarily
Solution
Step 1: Understand host-based routing for multiple hosts
To route traffic by host, define separate rules for each host under spec.rules.Step 2: Compare options for best practice
Create two rules under spec.rules, each with a different host and paths pointing to their respective services. correctly uses two rules with different hosts and paths to route traffic properly.Final Answer:
Create two rules under spec.rules, each with a different host and paths pointing to their respective services. -> Option CQuick Check:
Multiple hosts need separate rules = Create two rules under spec.rules, each with a different host and paths pointing to their respective services. [OK]
- Using one host with path prefixes instead of separate hosts
- Creating multiple Ingresses unnecessarily
- Not specifying hosts and relying on paths only
Ready to prove it?
Pass the test and this pattern moves unknown
