What is a Ingress Controller?

How a Kubernetes Ingress Controller Works

The Ingress Controller runs as a process inside the cluster and watches the Kubernetes API for changes to Ingress Resources, Services, Endpoints, Secrets, and ConfigMaps. It uses Kubernetes Informers, specifically FilteredSharedInformer, to detect cluster state changes efficiently without constant polling.

When the controller detects a change, it rebuilds an internal configuration model and compares it to the currently running state. A reload happens only if the configuration actually changed. This avoids unnecessary service disruptions. For endpoint-only changes, such as a pod being added or removed from a Service, most controllers update backend pools dynamically through Lua handlers rather than triggering a full reload. This distinction matters in large clusters with frequent deployments, where reload frequency directly affects request success rates.

The routing model supports three path-matching types: Prefix, Exact, and ImplementationSpecific. The controller enforces precedence rules when multiple paths match a request. IngressClass resources link specific Ingress objects to the controller handling them, which allows multiple controllers to coexist in the same cluster without conflict. TLS termination happens at the controller level using Secrets referenced in the Ingress Resource, so upstream services receive plain HTTP internally. For teams managing cloud infrastructure management services, the Ingress Controller is typically one of the first components configured after a cluster is provisioned.

Why a Kubernetes Ingress Controller Matters

Without an Ingress Controller, each Kubernetes Service that needs external access requires its own cloud load balancer. For a mid-sized application with eight to twelve services, that means eight to twelve separately managed load balancers, each with its own cost, configuration, and certificate. Ingress consolidates external access into a single entry point, with routing rules declared in version-controlled YAML alongside the application code.

The scale of Kubernetes adoption makes this relevant across nearly every production infrastructure team. According to the CNCF 2025 Annual Cloud Native Survey, 82% of container users now run Kubernetes in production environments. That means 82% of container users have a traffic management decision to make for every service they expose externally. Ingress provides the standard answer: one controller, one configuration surface, automated certificate management through integrations like cert-manager, and routing rules that update without manual intervention. Teams running AWS-hosted Kubernetes environments typically deploy an AWS ALB Ingress Controller to stay within the native cloud toolchain, while on-premises or hybrid clusters more commonly use NGINX or Traefik.

Kubernetes Ingress Controller vs. Gateway API

The key difference is scope. The Ingress API handles HTTP/HTTPS routing within a single namespace, while Gateway API supports multiple protocols, cross-namespace traffic policies, and role-oriented configuration that separates infrastructure from application concerns.

Common Misconceptions

An Ingress Controller does not handle TCP or UDP traffic. The Kubernetes Ingress API is HTTP/HTTPS only. Teams that need to expose TCP-based services such as databases or message brokers must use a Service of type LoadBalancer or NodePort, or adopt the Gateway API.

An Ingress Controller is not deprecated or being removed. The Kubernetes Ingress API reached stable status in v1.19 and remains fully supported. Development on the Ingress spec is frozen, meaning no new features are being added, but existing Ingress Resources continue to work without changes. The Gateway API is the recommended path for new deployments requiring advanced routing capabilities, not a replacement mandate.