Alright, let’s talk about the future. You remember Ingress, right? The resource we just spent a chapter on? It’s… fine. It got us this far. But it’s a bit like trying to run a modern logistics company using a map drawn on a napkin. It works for basic “send this truck from A to B” stuff, but the moment you need complex routing, traffic splitting, or any semblance of a standard interface, you’re duct-taping annotations to it and praying.
Alright, let’s get our hands dirty with annotations. Forget the dry, academic definition. Think of annotations as the little sticky notes you slap onto your Kubernetes YAML to give the Ingress controller very specific, often non-standard, instructions. They’re how you access the real power—and the real quirks—of your chosen controller (NGINX, Traefik, HAProxy, etc.). The crucial thing to remember, the hill I will die on explaining, is this: Annotations are controller-specific. An annotation that works magic with the NGINX Ingress Controller will be completely ignored by Traefik, and vice versa. This is the biggest “gotcha” in the entire Ingress ecosystem. It means your manifests are subtly (or not so subtly) tied to your implementation choice. It’s not portable, and we all just have to live with that.
Look, manually managing TLS certificates is the digital equivalent of hand-washing every dish you use. It’s a noble, character-building exercise for about five minutes before you start wondering why you aren’t using the dishwasher. That dishwasher is cert-manager. It’s a Kubernetes-native utility that automates the procurement, renewal, and management of TLS certificates from a variety of Issuers, most famously Let’s Encrypt. It turns a tedious, error-prone process into a declarative “set it and mostly forget it” affair.
Right, so you’ve got your Ingress set up and traffic is flowing. But unless you’re running an internal-only service for masochists, you’re going to want to encrypt that traffic. This is where TLS termination comes in. The Ingress controller acts as the endpoint for your TLS connections, decrypting the traffic and passing plain old HTTP to your backend pods. It’s the bouncer that checks IDs at the door so the party inside (your app) doesn’t have to.
Right, so you’ve got a cluster, and you’ve got pods running your app. Wonderful. But users aren’t going to type http://10.244.2.15:8080 into their browser to see your masterpiece, are they? This is where the Ingress resource comes in. Think of it as the world’s most configurable, slightly fussy bouncer for your club. Its job is to look at incoming HTTP/HTTPS requests and, based on rules you give it, decide which service inside the cluster gets to handle it. We’re going to talk about the two main ways you instruct this bouncer: by the host you’re asking for, and by the path on that host.
Alright, let’s get our hands dirty. You’ve got a Kubernetes cluster, and you’ve got services running inside it. The million-dollar question is: how do people outside the cluster actually talk to them? You don’t just wave a magic wand. You need a traffic cop, a bouncer, a translator—all rolled into one. That’s what an Ingress resource is, a set of rules. But the thing that actually does the work, the muscle behind the rules, is the Ingress Controller.
Look, you’ve got your Pods running. You’ve defined a Service to give them a stable IP and load balance between them. You’re feeling pretty good. But then you realize: “Wait, how do I get traffic from the internet to this Service?” You can’t just set type: LoadBalancer on every single Service; your cloud provider will send you a strongly worded bill, and you’ll have a dozen IPs to manage. And what about SSL termination? And path-based routing? My god, the Service object has no idea what a “URL path” even is. It’s just… load balancing TCP.