How Do Ingress Controllers Compare?

intermediate|ingressdevopssreplatform engineerCKA

TL;DR

Ingress controllers are the runtime that implements Ingress rules. Popular options include Nginx Ingress Controller (most widely used, annotation-heavy), Traefik (auto-discovery, middleware), HAProxy (high performance), and cloud-native controllers like AWS ALB and GCE. Each differs in features, performance, and configuration approach.

Detailed Answer

An Ingress controller is the actual reverse proxy that reads Ingress resources and configures routing. The Ingress API is just a specification — without a controller, nothing happens. Choosing the right controller depends on your performance needs, feature requirements, and infrastructure.

Major Ingress Controllers

1. Nginx Ingress Controller

The most popular option, maintained by the Kubernetes community:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rate-limiting: "true"
    nginx.ingress.kubernetes.io/limit-rps: "100"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80

Strengths: Mature, well-documented, huge annotation library, wide community support Weaknesses: Configuration via annotations can be unwieldy, reload-based updates

2. Traefik

A cloud-native reverse proxy with automatic service discovery:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    traefik.ingress.kubernetes.io/router.middlewares: default-rate-limit@kubernetescrd
spec:
  ingressClassName: traefik
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80

Strengths: Dynamic configuration (no reloads), built-in dashboard, middleware system, Let's Encrypt integration Weaknesses: More resource-intensive, CRD-based configuration adds complexity

3. HAProxy Ingress

High-performance option for demanding workloads:

Strengths: Excellent performance under high concurrency, fine-grained connection tuning Weaknesses: Smaller community, fewer features than Nginx

4. AWS ALB Ingress Controller

Provisions AWS Application Load Balancers:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:...
    alb.ingress.kubernetes.io/waf-acl-id: ...
spec:
  ingressClassName: alb
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80

Strengths: Native AWS integration (WAF, ACM, Shield), no in-cluster proxy overhead Weaknesses: AWS-only, per-ALB cost, slower to converge

Comparison Matrix

| Feature | Nginx | Traefik | HAProxy | AWS ALB | |---|---|---|---|---| | Protocol support | HTTP/HTTPS/gRPC/WebSocket | HTTP/HTTPS/gRPC/TCP/UDP | HTTP/HTTPS/TCP | HTTP/HTTPS/gRPC | | TLS termination | Yes | Yes | Yes | Yes (ACM) | | Rate limiting | Via annotations | Via middleware | Via config | Via WAF | | Auto-TLS (Let's Encrypt) | With cert-manager | Built-in | With cert-manager | ACM | | Configuration | Annotations | CRDs + Annotations | Annotations | Annotations | | Hot reload | Reload-based | Dynamic (no reload) | Reload-based | API-driven | | Runs in cluster | Yes | Yes | Yes | No (cloud LB) | | Multi-cloud | Yes | Yes | Yes | No |

Installation Example (Nginx)

# Install with Helm
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=2 \
  --set controller.resources.requests.cpu=250m \
  --set controller.resources.requests.memory=256Mi

Decision Guide

Default choice: Nginx Ingress Controller — works everywhere, well-documented
Dynamic environments: Traefik — no-reload configuration, middleware support
High throughput: HAProxy — optimized for connection handling
AWS-native: ALB Controller — leverages AWS services (WAF, ACM, Shield)
Multi-cluster/mesh: Consider Gateway API instead of Ingress

Why Interviewers Ask This

Interviewers ask this to evaluate your practical experience with production Kubernetes networking and your ability to select the right tool for specific requirements.

Common Follow-Up Questions

Can you run multiple Ingress controllers in the same cluster?

Yes. Use IngressClass to assign each Ingress resource to a specific controller. This is common when different teams need different features or security requirements.

What is the most common Ingress controller?

The Nginx Ingress Controller (kubernetes/ingress-nginx) is the most widely deployed. It is maintained by the Kubernetes community and supported across all platforms.

How do cloud-native Ingress controllers differ from self-managed ones?

Cloud-native controllers (AWS ALB, GCE) provision cloud load balancers directly and offer native integration with cloud features like WAF and certificates, but lock you into a specific cloud provider.

Key Takeaways

Nginx Ingress Controller is the default choice for most clusters due to its maturity and broad feature set.
Cloud-native controllers offer deep integration but reduce portability.
Choose based on requirements: performance, features, middleware support, and cloud integration.