Ingress & Exposing Services Externally

Kubernetes Fundamentals

Chapter 9 · Ingress & Exposing Services Externally

Chapter 6 covered exposing a single Service externally. This chapter covers a genuinely common real need Chapter 6 didn't fully solve: exposing multiple services through a single entry point, with smarter routing than a plain LoadBalancer Service provides.

The Limitation of LoadBalancer Services, Revisited

A LoadBalancer Service provisions one external cloud load balancer per Service. Ten services each needing external exposure means potentially ten separate cloud load balancers — each with its own cost (cloud1-9's own cost material) and its own external IP. A plain LoadBalancer Service also operates at Layer 4 (cloud1-5's own L4/L7 distinction) — it has no understanding of HTTP paths or hostnames at all, just raw TCP/UDP forwarding. A genuinely common real need it can't solve: routing app.example.com/api to one service and app.example.com/web to another, through one shared entry point.

What Ingress Actually Is

An Ingress is a set of rules describing how external HTTP(S) traffic should be routed to internal Services, based on hostname and/or URL path.

An Ingress resource by itself does nothing

Critically, an Ingress requires an Ingress controller actually running in the cluster to read and implement those rules. Creating Ingress YAML with no controller installed accomplishes nothing at all — a genuinely common early confusion worth stating directly. Common controllers: the NGINX Ingress Controller, and cloud-provider-specific ones (AWS Load Balancer Controller, GCP's own, Azure's own). These often integrate with the provider's own LoadBalancer mechanism (Chapter 6) to get traffic into the cluster in the first place, then the controller's own Layer 7 logic takes over routing from there.

Host-Based & Path-Based Routing

Host-based — api.example.com routes to api-service; app.example.com routes to a different frontend-service — both sharing the same external IP/load balancer.
Path-based — example.com/api/* routes to api-service; example.com/* (everything else) routes to frontend-service.

Both can be combined. This directly closes the loop on the "10 services, 10 load balancers" cost problem — one Ingress, one external entry point, routing to many internal Services by rule.

A Concrete Ingress YAML, Explained

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80

Yet another distinct API group — networking.k8s.io/v1 — reinforcing Chapter 5's own point that apiVersion varies by kind. Every backend referenced is an ordinary Chapter 6 Service — Ingress routes to Services, it doesn't replace them.

TLS Termination at the Ingress

An Ingress can also handle TLS/HTTPS termination centrally — one place to manage certificates (https1's TLS material, crypto1's certificate chain material) for many backend services, rather than configuring TLS separately in every individual service. A genuine, practical reduction in operational complexity beyond just routing.

Ingress vs. Service LoadBalancer — When to Use Which

Need	Right choice
A single service, or Layer 4/non-HTTP traffic (raw TCP, a database)	LoadBalancer Service directly
Multiple HTTP(S) services sharing one entry point, host/path routing, centralized TLS	Ingress

Genuinely common in practice: many real clusters use both — an Ingress for the bulk of HTTP services, and a small number of standalone LoadBalancer Services for anything that doesn't fit the HTTP routing model.

10 services = 10 load balancers = a real, multiplied cost

Directly echoing cloud1-9's cost material: exposing every HTTP service individually via its own LoadBalancer Service multiplies real infrastructure cost unnecessarily when a single Ingress could route all of them through one shared entry point instead.

Hands-On Exercises

Exercise 1

Explain why creating an Ingress YAML resource alone, with no Ingress controller installed in the cluster, accomplishes nothing. What's actually missing?

📄 View solution

Exercise 2

Five different HTTP microservices all need to be reachable from the internet under the same domain, on different paths. Explain why using five separate LoadBalancer Services would be a worse choice than a single Ingress, referencing both cost and Layer 4 vs. Layer 7 capability.

📄 View solution

Exercise 3

Explain the benefit of TLS termination at the Ingress level rather than configuring TLS separately in each backend service.

📄 View solution

Chapter 9 Quick Reference

LoadBalancer Services are one-per-service and Layer 4 only — no HTTP host/path awareness
An Ingress defines HTTP(S) routing rules — but does nothing without an Ingress controller actually running
Host-based and path-based routing, combinable, all through one shared external entry point
Ingress uses yet another apiVersion (networking.k8s.io/v1); backends are ordinary Services (Ch.6)
Centralized TLS termination at the Ingress reduces real operational complexity
Single/non-HTTP service → LoadBalancer directly; many HTTP services sharing an entry point → Ingress; real clusters often use both
Next chapter: Namespaces & Resource Management — organizing a cluster, resource requests/limits, basic quotas