# Demonstration: Tracing a Request Through Ingress

## The setup

An Ingress `web-ingress` routes `app.example.com/` to Service `web-svc`, which fronts a
Deployment `web-app`. Nothing works yet from outside the cluster — let's see why, step by step.

## Step 1: is the Ingress object even doing anything?

```
$ kubectl get ingress web-ingress
NAME           CLASS     HOSTS               ADDRESS   PORTS   AGE
web-ingress    traefik   app.example.com               80      2m
```

`ADDRESS` is empty. On a real cluster, this column fills in once the Ingress controller has
actually processed the object and assigned it a reachable address — an empty address after a
couple of minutes is the first sign to check the controller itself, not your YAML.

## Step 2: is the controller running at all?

```
$ kubectl get pods -n kube-system -l app.kubernetes.io/name=traefik
NAME                       READY   STATUS    RESTARTS   AGE
traefik-7d8f9c6b5d-abcde   1/1     Running   0          10d
```

Running fine — so the ADDRESS delay in this case is transient, not a missing controller. (If
this returned no Pods at all, THAT would be the actual root cause — no controller means no
Ingress object ever gets acted on, exactly like the demonstration in ROOT 07's Ingress lesson
described.)

## Step 3: once ADDRESS populates, does the route actually work?

```
$ kubectl get ingress web-ingress
NAME           CLASS     HOSTS               ADDRESS        PORTS   AGE
web-ingress    traefik   app.example.com     10.0.1.50      80      3m

$ curl -H "Host: app.example.com" http://10.0.1.50/
<html>...web-app's real response...</html>
```

Success — but notice the `-H "Host: app.example.com"` header. Ingress routes by HOSTNAME, not
just by IP — hitting the Ingress controller's address WITHOUT the matching Host header would
route differently (or not at all), because that's literally what the Ingress rule is matching
on.

## The general shape

Symptom (nothing reachable from outside) has at least three DIFFERENT possible layers: the
Ingress object itself, the controller processing it, and the Service/Pod chain underneath it
(already covered in ROOT 07's Services module). Check them in that order — Ingress ADDRESS,
then controller health, then the underlying Service — rather than guessing at DNS or firewall
issues first.

## Instructor Notes

**Demo script:** If a real Ingress controller is available in the demo environment, run this
live including the Host-header nuance — students are frequently surprised that `curl <ip>`
alone doesn't work the way they expect.

**Approximate timing:** 8-10 minutes live; 5-7 minutes self-paced.

**Common misconception to preempt:** students often expect an Ingress's IP/address to work like
a Service's ClusterIP (reachable directly, no extra header needed). Reinforce that Ingress
routing is fundamentally HOSTNAME/PATH-based, which is exactly what makes one Ingress able to
route many different domains through one entry point.

**Optional extension:** ask what would happen if TWO Ingress objects both claimed the same host
+ path — a good forward pointer to why Ingress configuration conflicts are a real operational
concern on a shared cluster, without needing to build a hands-on lab around it here.