Ingress Controller

An Ingress controller is the component that makes Kubernetes Ingress resources work. An Ingress describes HTTP and HTTPS routing rules, and the controller watches those resources and configures a proxy or cloud load balancer to enforce them. Creating an Ingress without a controller has no effect.

How it works

An Ingress lists rules based on hostname and path, plus a backend Service for each rule. The ingressClassName field selects which IngressClass, and therefore which controller, handles that Ingress. If you omit it, a default IngressClass should exist. Valid path types are Exact, Prefix and ImplementationSpecific.

Controllers differ in implementation. Some run a proxy inside the cluster, such as NGINX or Traefik. Cloud controllers provision managed load balancers: the AWS Load Balancer Controller creates Application Load Balancers on EKS, and the Application Gateway Ingress Controller works with Azure Application Gateway on AKS. Features such as TLS termination, authentication or weighted routing vary by controller and are often set through annotations.

A practical example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
spec:
  ingressClassName: nginx
  rules: [{host: app.example.com, http: {paths: [{path: /, pathType: Prefix, backend: {service: {name: web, port: {number: 80}}}}]}}]

This sends traffic for one hostname to the web Service, provided a controller handling the nginx class is installed.

Common mistakes

• Applying an Ingress and wondering why nothing happens, when no controller is installed or the class does not match.
• Relying on controller-specific annotations, which makes moving between controllers harder.
• Forgetting certificate management. Plan how TLS certificates are issued and renewed.
• Overlooking project status. The Kubernetes project announced that best-effort maintenance of the Ingress NGINX controller ends in March 2026, with no further releases or security fixes after that. Existing installations keep working but unmaintained.

When to use it and when not to

The Ingress API is generally available and the project has no plans to remove it, but it is frozen, and the project recommends Gateway API for new designs. Ingress remains reasonable for simple HTTP routing on existing clusters. For service-to-service traffic inside the cluster, look at a service mesh rather than Ingress. See our Kubernetes consulting page for platform design help.

See also

• Kubernetes
• EKS
• AKS
• Service Mesh