An Ingress object defines how external HTTP or HTTPS requests reach Services inside a Kubernetes cluster. Its rules match request hostnames or paths; an ingress controller running in the cluster interprets those rules and forwards traffic. Create the backend Service first: an Ingress routes to a Service, not directly to a Deployment. section 6.3
To expose an application and verify the route:
- Install an ingress controller and check that its controller pod is running with `kubectl -n ingress-nginx get all`. section 6.3
- Create the workload and its Service: `kubectl create deploy hello --image nginxdemos/hello:plain-text --port 80`, then `kubectl expose deploy hello --name hello-svc --port 80`. Check both with `kubectl get deploy,svc`. section 6.3
- Apply an Ingress rule for host `hello.com` and path `/`, with backend Service `hello-svc` on port 80. Check the declared host with `kubectl get ing`. section 6.3
- Make `hello.com` resolve to the cluster endpoint, then run `curl hello.com` and check for the application's response. The hostname must resolve before the request can reach the controller. section 6.3
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hello
spec:
rules:
- host: hello.com
http:
paths:
- pathType: ImplementationSpecific
path: "/"
backend:
service:
name: hello-svc
port:
number: 80
- host: app.hello.com
http:
paths:
- pathType: Exact
path: "/"
backend:
service:
name: nginx
port:
number: 8080
Inspect the `networking.k8s.io/v1` manifest: each host rule contains a path, a `pathType`, and a Service name and port. Its second rule sends `app.hello.com` to a different Service, showing how one Ingress can route to multiple backends. section 6.3
Choose path matching deliberately: `Prefix` matches URL prefixes, while `Exact` matches the specified path string. If a request does not reach the intended application, check the controller, the Ingress host and path, the backend Service and port, and hostname resolution. section 6.3
