Ingress Rules and Ingress Controllers
An Ingress is only a request. Something has to implement it, and if nothing claims it the object sits there looking healthy forever. This creates that exact failure first, then a working two-path Ingress, and finishes with the behaviour that surprises people most: the matched path is passed to the backend unchanged.
Services and Networking Guide 36 of 44 Intermediate
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 17 min
- Reviewed23 August 2026
Written against the versions above. This cluster's ingress-nginx runs as a **NodePort** Service, so the address the Ingress advertises has nothing listening on port 80 - traffic goes to the controller's ClusterIP from inside, or its NodePort from outside. On a cloud cluster the same Service would be a LoadBalancer and the advertised address would answer on 80 directly.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A cluster with an ingress controller installed and an IngressClass. Without one, every Ingress here behaves like the broken first example.
- The session creates namespace
ckad-ingwith two backends serving content at/shopand/blog, an Ingress with no class, and an Ingress withingressClassName: nginx.
-
Two backends that serve their own path
-
An Ingress with no class
-
With a class, it is programmed
-
Does it route
-
The path reaches the backend unchanged