Chapter 34 Kubernetes: Ingress, Gateway API & Service Mesh
The edge and the mesh in depth: ingress-nginx internals and its retirement, cert-manager with ACME, external-dns, Gateway API status and traffic rules, migrating Ingress to Gateway, and Istio: injection, mTLS, authorization, retries, timeouts, faults and reading Envoy.
In plain words
Think of a large office building. At the front door there is a reception desk: visitors show who they are coming to see, reception checks the list and sends them to the right floor. Inside, staff walk between offices all day, and nobody checks them at every door, until the company decides that every office door gets a badge reader too.
Traffic into a cluster is the visitor at the front door: an ingress controller or a Gateway decides which Service a request for shop.lab reaches, ends TLS and hands out errors when something is wrong. Traffic between Services is the staff in the corridors: a service mesh puts a proxy next to every pod, so every call is encrypted, identified, retried and measured. This chapter goes deep on both, plus the certificates and DNS records that keep the front door working.
Why it matters on call
Almost every incident with "the site is down" in it passes through the edge: a 502 from the controller, a certificate that did not renew, a route a Gateway silently ignores. Being the person who reads the controller's log line or the route's status conditions and names the broken object in two minutes is a very visible skill on a platform team.
The ground is also moving: ingress-nginx was retired in March 2026, so teams are migrating to Gateway API right now, and interviews ask about it. Meshes such as Istio show up in most larger companies, and their failures (a STRICT policy cutting off old clients, a retry storm, a 503 with a response flag) look baffling until you can read an Envoy access log. This chapter makes all of that routine.
Lessons
- North-south and east-west: the traffic map
- ingress-nginx in depth: the generated config, the ConfigMap, the annotations
- Reading a 404, 502, 503 and 504 from ingress-nginx
- Certificates that renew themselves: cert-manager and ACME
- DNS that follows your Services: external-dns
- Gateway API in depth: roles, listeners, and what status tells you
- HTTPRoute traffic management: matches, filters, timeouts, mirrors
- Migrating from Ingress to Gateway API
- What a service mesh gives you, and what it costs
- Istio: install, injection and the control plane
- Mutual TLS and authorization in the mesh
- Traffic policy: VirtualService, DestinationRule, retries, timeouts, faults
- Reading Envoy: the access log, response flags and proxy-config
- Mesh telemetry: golden signals from every proxy
- Ambient mode, Linkerd, and when not to use a mesh
38 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Do I need a service mesh to use Gateway API?
No. Gateway API is a set of Kubernetes resources for routing traffic; many implementations exist, and the lab's main one (NGINX Gateway Fabric) has nothing to do with a mesh. Istio happens to implement Gateway API as well, and the GAMMA work lets routes describe mesh traffic, but you can run a Gateway with no mesh at all.
Is ingress-nginx still safe to run?
It still works, but since its retirement in March 2026 it gets no new releases and no security fixes, so every new vulnerability stays open. Running it for a while during a planned migration is common; planning to keep it for years is a risk you should write down. The chapter shows how to inventory annotations and move to Gateway API.
Why does the chapter use a lab ACME server instead of Let's Encrypt?
The lab has no internet, and Let's Encrypt would refuse .lab names anyway. Pebble is a small ACME server made for testing: cert-manager talks to it with the same protocol (accounts, orders, HTTP-01 challenges) it uses with Let's Encrypt. Everything you learn about the Certificate, Order and Challenge objects carries over unchanged.
Are the Istio outputs real?
The commands, status fields, access log format and response flags follow Istio 1.31 and Envoy as they print them. The simulator models the decisions (routing, retries, mTLS, policies) rather than running Envoy, so timings are simplified; things that exist only for the lab, such as the shop images, are labelled (simulator).
How much of this is on the job versus interview-only?
Most of it is daily work for a platform team: reading 5xx errors at the edge, fixing stuck certificates, writing routes for app teams, and debugging mesh policies. The comparison topics (sidecar versus ambient, Istio versus Linkerd, when not to use a mesh) are where interviews go deeper than a typical week, so the last lesson covers them.