Ingress Rules and Ingress Controllers

Services and Networking / Guide 36 of 44 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 17 min

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.

This guide includes

Use this when an Ingress is applied and no address ever appears. This matters because an Ingress is only a request - with no ingressClassName nothing claims it, and it sits there valid and unprogrammed indefinitely.

• standing up two backends that each serve their own path
• applying a perfectly valid Ingress with no class, and watching nothing ever claim it
• adding ingressClassName: nginx and watching it get programmed
• proving both paths reach the Service they are supposed to
• confirming the path reaches the backend unchanged, with no rewrite involved

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-ing with two backends serving content at /shop and /blog, an Ingress with no class, and an Ingress with ingressClassName: nginx.

1. 1

   Two backends that serve their own path

2. 2

   An Ingress with no class

3. 3

   With a class, it is programmed

4. 4

   Does it route

5. 5

   The path reaches the backend unchanged

Official sources

• Ingress
• Ingress Controllers
• ingress-nginx rewrite