An ingress routing rule maps an HTTP request to a backend service by examining its host and path. A rule can expose a ClusterIP Service without making that Service directly reachable from outside the cluster. section 12.2.1
Each rule contains a host, one or more paths, a path-matching mode, and a backend service port. For example, kiada.example.com with path / and Prefix sends requests to port 80 of the kiada Service, regardless of the remaining path. section 12.2.1
Path matching determines which requests a rule accepts:
- Exact matches the complete requested path, so /quote matches /quote but not /quote/random. section 12.2.2
- Prefix matches path elements from the beginning, so /questions matches /questions and /questions/random but not /questionnaire. section 12.2.2
- ImplementationSpecific leaves matching behavior to the Ingress controller. section 12.2.2
Route two paths through one host
A rule for api.example.com can send the exact path /quote to the quote Service and the /questions prefix to the quiz Service. The proxy does not rewrite the URL path by default. section 12.2.2
Listing 12.3 Ingress mapping request paths to different services
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-example-com
spec:
rules:
- host: api.example.com #1
http:
paths:
- path: /quote #2
pathType: Exact #2
backend: #2
service: #2
name: quote #2
port: #2
name: http #2
- path: /questions #3
pathType: Prefix #3
backend: #3
service: #3
name: quiz #3
port: #3
name: http #3
Use the manifest to inspect how host, pathType, service name, and service port combine into routing entries. section 12.2.2
An Ingress object can consolidate rules for several hosts and services behind one public IP. Exact host matches take precedence over wildcard hosts, and a wildcard such as *.example.com covers one DNS name element. section 12.2.3
