An ingress controller implements Ingress rules that route external HTTP and HTTPS requests to Services inside a Kubernetes cluster. The Ingress resource declares which hostname or path reaches each Service; the controller interprets those rules. Install a controller as well as creating an Ingress—rules alone do not provide the routing component. section 6.3
For an exam-style setup, work from the controller to a verified request:
- Apply an ingress-nginx controller manifest, then run `kubectl -n ingress-nginx get all`. Check that the controller Deployment and pod are ready and that its Service exists. section 6.3
- Create a 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`. Use `kubectl get deploy,svc` to check the Deployment and ClusterIP Service. section 6.3
- Create an Ingress whose `hello.com` rule sends `/` to `hello-svc` on port 80. Check its host with `kubectl get ing`. After arranging hostname resolution to the reachable node address, use `curl hello.com` to verify that the workload responds. section 6.3
One Ingress, two destinations
A `networking.k8s.io/v1` Ingress can route `hello.com/` to `hello-svc:80` and `app.hello.com/` to a different Service, `nginx:8080`. Rules can also distinguish request paths: `Prefix` matches URL prefixes, while `Exact` matches the specified path. Check the host and path before troubleshooting the backend Service. 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 Ingress manifest for the host, path type, backend Service name and port in each rule. section 6.3
