Ingress & Ingress Controllers

In one line

An Ingress routes external HTTP(S) traffic to many different Services through ONE shared entry point, based on hostname and path — the standard alternative to provisioning a separate LoadBalancer per service.

0/4 · 0%

Think of it like this

A single building receptionist directing every visitor to the correct floor and office based on who they're asking for, rather than every single office needing its own dedicated street entrance — an Ingress is exactly this shared front door for many services at once.

Key ideas

01
Topic 1.2 already flagged the problem: a LoadBalancer Service provisions one real, separately-billed cloud load balancer PER service — genuinely wasteful and unwieldy once you have many services that each need external HTTP access. An INGRESS solves this by routing external traffic to MANY Services through a single shared entry point, based on the request's HOSTNAME and PATH.
02
An Ingress object itself is just a set of ROUTING RULES ('requests to api.example.com go to the api Service; requests to example.com/blog go to the blog Service') — it does nothing on its own without an INGRESS CONTROLLER (a real running component, like NGINX Ingress Controller or Traefik) actually installed in the cluster to read and enforce those rules.
03
This split (Ingress = the rules you write; Ingress Controller = the actual software enforcing them) is deliberate — Kubernetes ships the Ingress API as a standard, but lets you choose WHICH controller implementation actually fulfills it, similar in spirit to how a StorageClass (Phase 2.4) lets you choose which storage provisioner backs it.
04
A single Ingress Controller typically handles routing for MANY Ingress objects across the whole cluster, usually fronted by just ONE real LoadBalancer Service pointing at the controller itself — meaning you provision one real external load balancer total, no matter how many individual services and hostnames you're actually routing to behind it.
05
Ingress also commonly handles TLS TERMINATION — the Ingress object references a Secret (Topic 2.1) holding a TLS certificate, and the controller handles HTTPS decryption at the edge, so your actual application pods only ever need to deal with plain HTTP internally, exactly the reverse-proxy pattern Linux's own course (and Nginx specifically, on the DevOps roadmap this course draws from) covers at the OS level.

Code & diagrams

IngressRoutingdiagram

One external entry point, many services, routed by hostname and path.

Rendering diagram…

ingress.yamlmarkdown

Two hostnames, two different backend Services, one Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx      # which Ingress Controller should handle this
  tls:
    - hosts: ["api.example.com"]
      secretName: api-tls-cert  # references a Secret holding the TLS cert
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-svc
                port:
                  number: 80
    - host: example.com
      http:
        paths:
          - path: /blog
            pathType: Prefix
            backend:
              service:
                name: blog-svc
                port:
                  number: 80

ingress.shmarkdown

Confirm the controller is running, then inspect the routing rules it's enforcing.

# Confirm an Ingress Controller is actually installed — an Ingress does
# NOTHING without one
kubectl get pods -n ingress-nginx
# (namespace name varies by which controller is installed)

kubectl apply -f ingress.yaml

# See the Ingress and which controller/address is serving it
kubectl get ingress my-ingress

# Full details, including the routing rules exactly as the controller reads them
kubectl describe ingress my-ingress

Explain it without notes

Why does an Ingress object alone accomplish nothing without an Ingress Controller also installed in the cluster?

Why is an Ingress generally preferred over giving every single Service its own LoadBalancer type?

Practice

If you have access to a cluster with an Ingress Controller installed, create the example Ingress (adjusted for your own domain/services) and confirm with kubectl describe ingress that its rules match what you configured.

Look up which specific Ingress Controller (NGINX, Traefik, or another) is installed on any cluster you have access to, and identify the namespace its own pods run in.

Trade-offs

↔
An Ingress is more efficient and scalable than many individual LoadBalancer Services, but it adds a real extra layer (the controller itself, its own configuration and annotations, which are genuinely controller-specific and not portable between different Ingress Controller implementations) — for a genuinely simple cluster with just one or two services needing external access, a plain LoadBalancer Service may still be the simpler, more direct choice.

Done when you can

I understand the difference between the Ingress object (rules) and an Ingress Controller (the software enforcing them).
I can explain why Ingress scales better than one LoadBalancer Service per application.
I can create an Ingress routing multiple hostnames/paths to different backend Services.