An Ingress object declares how external HTTP or HTTPS requests reach Services in a Kubernetes cluster. It can expose several Services through one public entrypoint, rather than requiring a separate public IP address for each LoadBalancer Service. Its rules select a backend from the request’s host and path. section 12.0 section 12.1.1
The object is configuration, not the component that receives traffic. An ingress controller watches Ingress objects and related Service and endpoint information, then configures an L7 load balancer or reverse proxy. The cluster needs an ingress controller for these rules to take effect; one is not available out of the box in every cluster. section 12.1 section 12.1.2
Listing 12.2 An Ingress object exposing the kiada service at kiada.example.com
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: kiada-example-com #1
spec:
rules:
- host: kiada.example.com #2
http:
paths:
- path: / #3
pathType: Prefix #3
backend: #4
service: #4
name: kiada #4
port: #4
number: 80 #4
This minimal networking.k8s.io/v1 manifest sends requests for kiada.example.com, on any path, to port 80 of the kiada Service. The Service can normally remain type ClusterIP, although some controllers require NodePort. section 12.2.1
A rule can become more selective or cover more backends:
- Use pathType: Exact to match one path, or Prefix to match a path and its subpaths by path element. ImplementationSpecific leaves matching to the controller. The request path is not rewritten by default. section 12.2.2
- Put multiple host rules in one object to share a public IP where the ingress implementation supports it. A host can also use a single-DNS-element wildcard; an exact host match takes precedence. section 12.2.3
- Set a default backend to handle requests that match no rule. section 12.7
Route two paths to different Services
For api.example.com, map the exact path /quote to the quote Service and the prefix /questions to the quiz Service. Test both through the Ingress IP with curl --resolve; this supplies the hostname even before DNS is configured. For regular clients, point the rule’s hostname to the ingress proxy’s IP in DNS. section 12.2.2 section 12.7
After applying a manifest, use kubectl get ingresses to find its address and kubectl describe ing to inspect rules and backends. The address may change when an Ingress is replaced, so update DNS, /etc/hosts, or test commands accordingly. section 12.2.1 section 12.2.3
For HTTPS, reference a TLS Secret containing a certificate and private key in spec.tls; its configured hosts must match the certificate. The proxy can terminate TLS and forward HTTP to backend pods. When multiple controllers are installed, spec.ingressClassName selects an IngressClass and thereby the controller. Controller-specific extensions can also use annotations or custom resource backends. section 12.3.2 section 12.5 section 12.6.1
