What is an ingress controller?
An ingress controller is a program running in a Kubernetes cluster that watches Ingress objects and turns their rules into a working HTTP proxy. It accepts web traffic from outside the cluster, matches each request by hostname and path, and forwards it to the Service named in the rule.
Think of the front desk in an office building. Visitors all come through one entrance, and the receptionist checks the name on each visit and sends people to the right floor. The Ingress object is the list of names and floors; the controller is the receptionist who acts on it.
How do Ingress objects and controllers fit together?
An Ingress object on its own does nothing. Kubernetes stores it, but no traffic moves until a controller reads it and configures its proxy. Clusters do not ship with one, so you install a controller yourself.
Rules
Each rule has an optional host and a list of paths, and each path points to a Service and port. A request must match both the host and the path before it reaches that Service. Requests that match no rule go to a default backend, which is usually set in the controller.
TLS
An Ingress can reference a Secret that holds a certificate and private key. The controller then terminates TLS on port 443 and sends plain HTTP to the Pods. cert-manager can watch Ingress objects and issue those certificates for you.
Ingress classes
You can run several controllers in one cluster. Each Ingress names the one it belongs to with ingressClassName, and a default IngressClass catches Ingress objects that leave it out.
What can’t an Ingress do?
Ingress is limited to HTTP and HTTPS. Other protocols need a Service of type LoadBalancer or NodePort instead.
- No arbitrary TCP or UDP ports.
- Only one TLS port, 443.
- Anything beyond host and path matching depends on controller-specific annotations, which do not carry over between controllers.
The Ingress API is generally available and will not be removed, but it is frozen. New work should use the Gateway API instead. The community ingress-nginx controller was retired in March 2026 and gets no more security fixes.
How enum handles ingress controllers
enum Kubernetes Engine gives a Service of type LoadBalancer an L4 load balancer for TCP and UDP with an IPv4 address. There is no managed L7 load balancer, so you run your own Ingress or Gateway API controller behind it. enum DNS works with cert-manager for ACME DNS-01 certificates, wildcards included.
FAQ
Do I need an ingress controller for every cluster? Only if you want to route HTTP or HTTPS traffic with Ingress objects. Clusters that expose a single service, or only non-HTTP protocols, can use a Service of type LoadBalancer directly.
Should I use Ingress or the Gateway API? For new clusters, prefer the Gateway API, since the Ingress API is frozen and gets no new features. Existing Ingress objects keep working, and many controllers support both, so you can migrate one route at a time.
Can I move Ingress objects between controllers?
The basic host, path and TLS rules move unchanged. Annotations are specific to each controller and are ignored by others, so review and rewrite them, and set the new ingressClassName value.