We reach the moment the course has been promising since module 1: publishing Rutas Norte on the internet. We have five components deployed, all with ClusterIP Services that exist only inside the cluster, and no customer can buy a ticket. In 04-02 we saw that LoadBalancer would solve the problem at the price of one balancer and one public IP per service, with no routing by domain or by path. This lesson presents the right answer: a single HTTP entry point that distributes traffic according to the requested domain and path. By the end, www.rutasnorte.example will serve the store and api.rutasnorte.example will serve the API, both from the same balancer, and you will clearly distinguish between the Ingress resource —a rule that does nothing on its own— and the Ingress controller, the program that turns it into real configuration.

1. The problem: several HTTP services, a single entry point
2. Resource versus controller: the essential distinction
3. An overview of controllers
4. IngressClass and the legacy annotation
5. Anatomy of an Ingress
6. pathType: the three values and the confusing cases
7. Hands-on: publishing the store and the API
8. Host-based versus path-based routing and rewriting
9. Everyday annotations
10. Debugging
11. Gateway API: the successor

Rutas Norte needs to publish, as a minimum:

With type: LoadBalancer that would be four balancers, four public IPs and four TLS certificates managed separately, multiplied by the three environments. And even then the essential part would be missing: an L4 balancer does not understand HTTP. It cannot read the Host header to decide which service a request goes to, nor look at the path, nor rewrite it, nor add headers. Ingress moves the decision to layer 7:

One balancer, one IP, one place to terminate TLS (04-05), and all the internal services stay ClusterIP.

This is the number one confusion of the lesson and it must be nailed down before writing anything.

The symptom of creating an Ingress with no controller is deceptive: kubectl apply answers created, kubectl get ingress lists it and the domain does not respond. The clue is in the ADDRESS column, empty forever.

A controller is, on the inside, a loop identical to the one from module 1: it watches the API, reads the Ingresses, Services and EndpointSlices, generates a configuration file (an nginx.conf, in ingress-nginx) and reloads its proxy, using a ServiceAccount with permissions (03-06).

Beware one historical detail: there are two controllers based on NGINX. ingress-nginx is the Kubernetes project's one; "NGINX Ingress Controller" is F5/NGINX Inc's. Their annotations are not compatible, and many hours have been lost copying the one from the wrong controller. Here we use ingress-nginx, the one in the minikube addon.

The two Completed ones are Jobs (06-03) that install the validating webhook: thanks to it, an Ingress with invalid syntax is rejected at apply time instead of breaking the proxy configuration.

A cluster can have several controllers: a public one for web-store and bookings-api, an internal one for the admin panel. IngressClass says which controller serves which Ingress.

In the Ingress it is referenced with the field spec.ingressClassName: nginx. Before Kubernetes 1.18 this was done with the annotation kubernetes.io/ingress.class: "nginx", which still works in many controllers for compatibility but is discouraged and will disappear. You will see a huge number of examples on the internet using it: they are old. Use ingressClassName.

If you specify no class and none is marked as the default, no controller picks up the Ingress: empty ADDRESS and silence.

Constraints that cause most of the failures:

• The Ingress and the Services must be in the same namespace. An Ingress in rutas-norte-pro cannot point at a Service in rutas-norte-dev: it is a security design decision, not a technical limitation.
• The port can be number or name, but not both. Referencing it by name survives a change of number.
• host accepts a wildcard at the first level (*.rutasnorte.example), which matches api.rutasnorte.example but not www.api.rutasnorte.example nor the bare domain. Rules without host match any domain: handy for testing by IP, dangerous in production.

defaultBackend is the destination for anything that matches nothing: without it, the controller returns its generic 404; with it, a customer who mistypes the subdomain ends up in the store.

pathType is mandatory as of networking.k8s.io/v1 and its semantics surprise almost everybody.

The key to Prefix is in those three words "by path segments". /api is not a character prefix: it matches /api and /api/whatever, but it does not match /apiary.

Tie-breaking rule when several match: the longest path wins, regardless of pathType.

A request to /api/bookings matches both rules, and goes to bookings-api because /api is longer than /. This ordering by length, rather than by position in the YAML, avoids the "I put the more specific rule at the top and it does not work" mistake.

A single Ingress publishes both Rutas Norte domains.

Notice what you do not have to do: the Services are not changed to NodePort or LoadBalancer. They stay ClusterIP, because the one talking to them is the controller, which is inside the cluster.

Applying and checking:

ADDRESS holding the node's IP means the controller has picked up the Ingress. That field takes anything from a few seconds to a couple of minutes to appear; if it is still empty after five, something is wrong (section 10).

Rutas Norte's customers can now reach the platform: it is the first time in the course that traffic really comes in from outside the cluster. That the routing is done by the Host header and not by the IP is what we will check in exercise 1: same IP, same port, different results depending on the Host. That is L7 routing.

The alternative to two domains is serving the API under /api of the main domain.

Rutas Norte uses both: api.rutasnorte.example for the external agencies, and www.rutasnorte.example/api so the SPA does not have to deal with CORS.

The problem: the SPA asks for /api/bookings but bookings-api expects /bookings; without rewriting it would receive /api/bookings and return 404.

How to read that expression: /api matches the literal prefix; (/|$) is group 1 (a slash or the end of the string, so that both /api and /api/... match); (.*) is group 2, everything that comes after; and rewrite-target: /$2 rebuilds the path with group 2 alone.

And the warning: pathType becomes ImplementationSpecific because we are using a regular expression, something Prefix does not cover. That Ingress is not portable to Traefik or to the AWS ALB. It is a conscious trade-off.

A much-repeated caveat: rewriting affects the request path, not the URLs the application generates in its HTML or in its redirects. If bookings-api answers Location: /bookings/33, the browser will go there and not to /api/bookings/33. Applications served under a prefix must know about it (typically through a BASE_PATH variable).

Annotations are the mechanism by which each controller exposes its features; these are the ingress-nginx ones used on any real platform.

An example applied to the bank-holiday and summer traffic peaks:

Two important warnings:

• configuration-snippet is disabled by default in recent versions of ingress-nginx for security reasons (it allowed arbitrary proxy configuration to be injected from any namespace). It has to be enabled in the controller's ConfigMap, and it is worth thinking twice about.
• The limiting is applied per controller replica. With three replicas, a 20 rps limit is in practice 60.

Global settings (default headers, buffer sizes, log format) do not go in annotations but in the controller's ConfigMap, ingress-nginx-controller in the ingress-nginx namespace.

Always the first stop:

What to look at, in this order: Address filled in (somebody has picked up the Ingress); the right Ingress Class; the backends with pod IPs in brackets —if it says <error: endpoints "web-store" not found> or shows an empty list, the problem is not the Ingress, it is the Service, and you go back to the diagnosis of 02-05—; and Events with Sync, which confirms the controller applied the configuration.

The fields in brackets are gold: [rutas-norte-pro-bookings-api-http] is the chosen upstream, and 10.244.0.31:3000 the specific pod. If the upstream appears empty, no rule matched.

The distinction is worth memorising: 503 means there is nobody to send to (empty endpoints) and 502 means there is somebody to send to but they do not answer properly. Different layers.

Looking at the nginx.conf the controller generated from your Ingress settles any argument about what is going on: kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- cat /etc/nginx/nginx.conf | grep -A5 "server_name api.rutasnorte.example".

Ingress has aged badly. Its specification is so minimal that everything interesting ended up in proprietary annotations: rewriting, CORS, rate limiting, headers... None of it is portable. It also mixes responsibilities: whoever administers the infrastructure and whoever publishes an application edit the same object.

The Gateway API (gateway.networking.k8s.io) is the official answer, already stable for its main resources.

Concrete advantages over Ingress: role separation (the Rutas Norte team creates its HTTPRoute without touching the entry point); features in the model, not in annotations —rewriting, redirection, headers and weighted splitting are API fields, so the canary of 11-04 no longer needs specific annotations—; cross-namespace routes with explicit permission from the Gateway owner; and real portability between implementations.

Ingress is not deprecated and will keep working for many years: too much is deployed. But for a new platform in 2026 the Gateway API is worth evaluating, especially if Istio, Cilium or Traefik are already in use. Here we carry on with Ingress because it is what you will run into and what the module 12 certifications assess.

• Creating the Ingress with no controller. The apply goes fine and nothing works. Check kubectl get pods -n ingress-nginx first.
• Pointing at a Service in another namespace. Not possible. The Ingress lives in the namespace of its Services.
• Copying annotations from the wrong controller. nginx.ingress.kubernetes.io/* belongs to ingress-nginx; F5's uses nginx.org/*. They are not interchangeable.
• Using kubernetes.io/ingress.class. Obsolete. Use ingressClassName.
• Expecting Prefix to compare characters. /api does not match /apiary. It compares segments.
• Confusing 503 with 502. The first is "no endpoints"; the second, "the pod does not answer properly". Different diagnoses.
• Rewriting paths without the application knowing. The links and redirects it generates will still lack the prefix. Configure the application's BASE_PATH.
• Forgetting that routing depends on the Host header. Testing with curl http://IP/ without -H 'Host: ...' will give 404 even when everything is fine.
• Tip: one Ingress per application, not one giant one per cluster. They are deployed and rolled back independently.
• Tip: the timeout and body-size annotations are among the first ones needed in production. Set them from the start with sensible values instead of waiting for the first 413 on a bank holiday.

Enable the minikube ingress addon, create the Ingress that publishes www.rutasnorte.example against web-store and api.rutasnorte.example against bookings-api, resolve the domains in /etc/hosts and check both routes. Also prove that the routing is done by the Host header.

Add to the www.rutasnorte.example domain a /api path that reaches bookings-api without the prefix. Verify in the controller logs which path the backend actually receives and what happens with /apiary.

Reproduce and diagnose: (A) an Ingress with ingressClassName: traefik in a cluster with only ingress-nginx; (B) a correct Ingress whose Service points at a selector that does not match; (C) an Ingress whose backend.service.port.number is 8080 when the Service exposes 80. State the exact symptom of each and the command that identifies it.

Exercise 1

The 404 on the third proves that the decision is taken by reading the Host header, not the destination IP.

Exercise 2

The client asked for /api/health; the backend received /health. With /apiary, the regex /api(/|$)(.*) would match (because use-regex compares characters, not segments) and the backend would receive /ary — one more reason to prefer Prefix except when rewriting is unavoidable, and to anchor the expression better if it is a problem.

Exercise 3

The mistake in C is especially frequent: the Ingress port is the Service's (port), not the container's (targetPort). Confusing them produces an Ingress that looks correct and returns 503.

Rutas Norte is published. You understand the distinction that organises everything else: the Ingress resource is a declaration of intent that on its own does absolutely nothing, and the Ingress controller is the program that watches it, generates proxy configuration and actually routes the traffic; if the second is missing, the first is created without errors and the ADDRESS stays empty forever. You know the landscape of controllers, the danger of confusing ingress-nginx with F5's identically named controller, and you know how to select yours with ingressClassName instead of the obsolete kubernetes.io/ingress.class annotation.

You have mastered the object's anatomy: rules with host and http.paths, backend.service.name with the Service's port (not the container's), and defaultBackend for anything that matches nothing. You are clear that pathType: Prefix compares path segments and not characters —/api does not match /apiary— that Exact distinguishes the trailing slash and letter case, that ImplementationSpecific is the door to regular expressions at the cost of portability, and that when several rules match the longest one wins.

Above all, you have done the work: you enabled the ingress addon, published www.rutasnorte.example against web-store and api.rutasnorte.example against bookings-api with a single Ingress and a single entry point, resolved the domains with /etc/hosts and proved that the distribution is done by reading the Host header. You added the /api path with rewrite-target, understanding the regular expression group by group, and you know the annotations needed in production from day one: body size, timeouts, request limiting and security headers. You know how to debug with describe, with the controller logs and, as a last resort, by reading the generated nginx.conf, and you can tell a 503 (no endpoints) from a 502 (backend not answering) without hesitation. And you know that the Gateway API is the successor, with role separation and features in the model rather than in annotations.

One serious problem remains, and it is not one that can wait: all of this runs over plain HTTP. The personal data customers type in to make a booking —name, ID number, phone, email— and the data travelling towards the payment gateway are crossing the internet unencrypted. In 04-05 we will put HTTPS on both domains: first with a self-signed certificate for development, and then with cert-manager issuing and automatically renewing Let's Encrypt certificates through the ACME HTTP-01 and DNS-01 challenges.