Ingress Controllers

Ingress vs IngressClass — two separate objects

An Ingress object (Lesson 34) defines the routing rules — "requests for api.company.com/payments go to the payments-svc Service." An Ingress Controller (this lesson) is the actual running software that reads those rules and implements them. You must deploy an Ingress controller before any Ingress objects do anything. The controller watches for Ingress objects and reconfigures itself accordingly — in real time, no restart required.

What just happened?

One manifest, full installation — The apply command created a complete, production-ready ingress-nginx installation. The controller Deployment runs nginx pods. The LoadBalancer Service fronting it got an AWS NLB provisioned automatically — that DNS name is your single public endpoint for the entire cluster.

ingress-nginx-controller-admission — This ClusterIP Service is the admission webhook endpoint. When you apply an Ingress object, the Kubernetes API server sends it to this webhook for validation before persisting it. If your Ingress has invalid syntax (conflicting paths, unknown annotations), the webhook rejects it immediately with a clear error rather than silently creating a broken config.

IngressClass: nginx — The installation also created an IngressClass named nginx. Ingress objects reference this class with ingressClassName: nginx to tell Kubernetes which controller should handle them. If you run multiple Ingress controllers (different controllers for different namespaces or teams), IngressClass is how you direct each Ingress to the right controller.

What just happened?

ConfigMap changes require a controller restart — Unlike Ingress routing rules (which are picked up dynamically), changes to the main ingress-nginx ConfigMap require a controller restart to take effect. nginx reads its configuration on startup — a reload is needed to apply new global settings. The kubectl rollout restart triggers a graceful rolling restart of the controller pods.

Security headers on every response — By adding security headers in the controller ConfigMap, every single response flowing through the ingress — from every service, across every Ingress rule — gets those headers automatically. Application teams don't need to add them to their services individually. This is one of the highest-leverage platform team actions: one place, cluster-wide security improvement.

ssl-redirect: true — Once this is set, any HTTP request hitting the ingress controller gets a 308 Permanent Redirect to the HTTPS equivalent. You don't need to configure this in every Ingress object — the controller handles it globally. Users who accidentally type http:// get transparently upgraded.

What just happened?

replicaCount: 2 for HA — A single ingress-nginx controller Pod is a single point of failure. During a node drain or controller pod crash, external traffic would fail for a few seconds. Two replicas running on different nodes (enforced by default PodAntiAffinity in the chart) gives you zero-downtime controller upgrades and node maintenance without external traffic interruption.

Prometheus metrics + ServiceMonitor — With metrics.serviceMonitor.enabled=true, the Helm chart creates a ServiceMonitor resource. If Prometheus Operator is installed, it automatically starts scraping the controller's metrics: request rate, error rate, upstream response times, active connections, SSL handshake duration. This is your ingress observability layer — visible in Grafana dashboards without any manual configuration.

--reuse-values on upgrade — When upgrading the chart version, --reuse-values applies the new chart version with your existing value overrides preserved. Without it, a Helm upgrade reverts all custom settings to chart defaults — which has caused surprising production incidents when engineers forget to re-specify their values.

What just happened?

IngressClass gates which controller handles each Ingress — Each Ingress controller only processes Ingress objects that reference its IngressClass. The public controller with class nginx-public ignores all Ingress objects with ingressClassName: nginx-internal. This gives you clean separation: publicly-facing teams use the public IngressClass, internal teams use the internal one, and they never interfere with each other's routing rules.

is-default-class — When a cluster has a default IngressClass, any Ingress object without an explicit ingressClassName gets handled by the default controller. Only one IngressClass should have is-default-class: "true" at a time — having two defaults causes undefined behaviour where different controllers fight over the same Ingress objects.

Teacher's Note: The controller is infrastructure — treat it that way

The Ingress controller is as critical as your cluster's DNS (CoreDNS) or your kube-proxy. If it goes down, all external traffic to every HTTP service in your cluster stops. Yet I regularly see teams run a single ingress-nginx replica on a shared node with no resource limits and no monitoring. That's like running a production web server on a laptop with no backups.

Production checklist for your Ingress controller: (1) At least 2 replicas with podAntiAffinity to spread them across nodes. (2) Resource requests and limits set. (3) Prometheus metrics and alerting for error rate, latency, and 5xx responses. (4) TLS certificates managed by cert-manager (not manually). (5) Controller version pinned and upgrades tested in staging before production.

The Ingress rules (Lesson 34) are where developers spend most of their time — but the controller setup (this lesson) is where SREs focus. Getting the controller right once saves weeks of debugging later.

Up Next · Lesson 34

Ingress Rules

Writing the actual routing rules — host-based and path-based routing, TLS termination, annotations for rate limiting and auth, and the rewrite tricks that every backend engineer eventually needs.