TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

If you're not getting great results from AI, it's usually a prompting problem. Skill Leap's two free courses fix that.

The 14-Day AI Boot Camp gets you up to speed on ChatGPT, Gemini, and Midjourney fast. Prompting Essentials teaches the pro strategies that get better outputs every time. 37 lessons total.

Downloadable workbooks. Earn a LinkedIn certificate. Trusted by 5,000+ professionals. Free forever. No credit card, no catch.

Get 2 Free AI Courses

Looking to promote your company, product, service, or event to 50,000+ Cloud Native Professionals? Let's work together. Advertise With Us

When someone visits a domain like shop.amazon.com, that request has to land on the exact set of servers running the product catalog, not the ones running the REST API or the admin panel. A retailer running hundreds of services inside one cluster cannot expose each one on its own IP address.

A Service of type LoadBalancer provisions a real cloud load balancer per service, and at a few hundred services that becomes both an operational mess and a real line item on the AWS bill. Kubernetes solves this with a single entry point that reads the request and decides where it belongs before it ever touches a pod.

A single domain splits into distinct destinations based on the subdomain in the request. shop.amazon.com reaches the product catalog, api.amazon.com reaches the REST layer, admin.amazon.com reaches the internal panel, and cdn.amazon.com reaches static assets. Each of these can be a completely different set of pods, scaled independently, deployed independently, versioned independently, and this routing decision has to happen before the request reaches any of them.

An Ingress is a Kubernetes object that defines routing rules, which hostnames and paths map to which services, but the object itself does nothing on its own. It needs an Ingress Controller, a piece of software running inside the cluster, usually built on NGINX, HAProxy, or Envoy, that watches for Ingress objects and configures its own routing table to match.

This separation matters operationally. The Ingress resource is portable YAML that describes intent, while the controller is the thing actually doing TLS termination, header rewriting, and load balancing. Swap NGINX Ingress for HAProxy Ingress and most Ingress YAML keeps working, because the resource kind is standardized even though the controller implementation is not.

A client request hits a cloud load balancer that the Ingress Controller provisioned and manages. That load balancer forwards to the Ingress Controller pod, which reads its routing rules and sends the request to the correct Service based on hostname. Each Service then load balances across its own set of pods using label selectors, the same mechanism any Kubernetes Service uses regardless of Ingress. The Ingress layer only decides which Service gets the request, the Service still owns distributing it across replicas.

An Ingress rule is typically host based, path based, or both. A host based rule matches on the domain in the request, exactly what the diagram above shows. A path-based rule matches on the URL path against a single host, so amazon.com/checkout and amazon.com/reviews can route to two different services behind one domain. Most production Ingress configurations combine both, several hostnames, each with several paths, all defined in one Ingress resource or split across several.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)