Types of Ingress in Kubernetes

Ingress in Kubernetes is not a single implementation — it’s a spec + controller model. The Ingress resource defines rules; the Ingress Controller enforces them. There are many controllers, each with different strengths.

How Ingress Works (recap)

Internet
    │
    ▼
[ Cloud LB ]          ← created by controller (optional)
    │
    ▼
[ Ingress Controller ] ← watches Ingress resources, enforces rules
    │
    ├──→ /api    → Service A → Pods
    ├──→ /web    → Service B → Pods
    └──→ /admin  → Service C → Pods

1. NGINX Ingress Controller

The most widely used. Runs NGINX as a reverse proxy inside the cluster.

• Maintained by: Kubernetes community (ingress-nginx) and NGINX Inc. (nginx-ingress)
• Best for: General-purpose HTTP/HTTPS routing

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.example.com
      secretName: tls-secret
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80

Key features:

• Rate limiting, auth, CORS via annotations
• WebSocket support
• Custom NGINX config via ConfigMap
• Canary deployments via annotations

2. AWS ALB Ingress Controller (AWS Load Balancer Controller)

Provisions an AWS Application Load Balancer per Ingress resource (or shared).

• Best for: AWS EKS clusters, native AWS integration

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

Key features:

• Native AWS WAF, Shield integration
• Target type: instance or ip (direct pod routing)
• SSL termination via ACM certificates
• One ALB per Ingress, or shared via IngressGroup

3. Traefik

A cloud-native reverse proxy and load balancer. Highly dynamic — auto-discovers services.

• Best for: Dynamic environments, microservices, automatic TLS via Let’s Encrypt

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traefik-ingress
  annotations:
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
spec:
  ingressClassName: traefik
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Key features:

• Automatic Let’s Encrypt TLS (built-in ACME)
• Real-time dashboard
• Native support for middlewares (auth, rate limit, circuit breaker)
• Supports IngressRoute CRD for more power than standard Ingress

4. HAProxy Ingress

Uses HAProxy as the underlying proxy engine. Known for high performance and fine-grained control.

• Best for: High-throughput, low-latency, TCP + HTTP workloads

Key features:

• Very high connection throughput
• Advanced health checks
• TCP passthrough (non-HTTP traffic)
• Blue/green and canary traffic splitting

5. GKE Ingress (Google Cloud)

Native to GKE — provisions a Google Cloud Load Balancer.

• Best for: Google Kubernetes Engine clusters

metadata:
  annotations:
    kubernetes.io/ingress.class: "gce"
    kubernetes.io/ingress.global-static-ip-name: "my-static-ip"

Key features:

• Google Cloud Armor (WAF) integration
• Cloud CDN support
• Multi-cluster Ingress across regions
• Backend configs via BackendConfig CRD

6. Kong Ingress Controller

Built on Kong Gateway — an API gateway turned Ingress controller.

• Best for: API management, plugins ecosystem, enterprise features

Key features:

• Rich plugin ecosystem (auth, rate limiting, logging, transforms)
• KongPlugin CRD for attaching plugins to routes
• Supports gRPC, WebSocket, TCP
• Can act as a full API gateway

7. Istio Ingress Gateway

Part of the Istio service mesh. Uses Envoy proxy as the entry point.

• Best for: Clusters already using Istio, advanced traffic management

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: tls-secret
      hosts:
        - app.example.com

Key features:

• mTLS end-to-end
• Fine-grained traffic shifting (canary, A/B, mirroring)
• Full observability (traces, metrics)
• Uses VirtualService + Gateway CRDs instead of standard Ingress

Path Types

All Ingress controllers support three pathType values:

Comparison at a Glance

Choosing the Right One

• Starting out / general use → NGINX Ingress
• On AWS EKS → AWS ALB Controller
• On GKE → GKE Ingress
• Need auto TLS + dynamic config → Traefik
• Already using Istio → Istio Gateway
• Need API gateway features → Kong
• Ultra-high performance TCP/HTTP → HAProxy

Note :

Ingress NGINX is Retired (March 2026)

Kubernetes SIG Network and the Security Response Committee announced the retirement of Ingress NGINX. Maintenance was halted in March 2026 — after that point, there are no further releases, no bugfixes, and no security vulnerability updates. The GitHub repositories have been made read-only.

Why did this happen?

Despite being one of the most widely deployed ingress controllers in the ecosystem, the project suffered from a maintainer shortage that ultimately became unsustainable. The breadth of Ingress NGINX’s functionality, once considered a key strength, evolved into what maintainers described as insurmountable technical debt. Features such as arbitrary NGINX configuration via “snippets” annotations, initially valued for flexibility, came to be viewed as serious security vulnerabilities in modern cloud-native contexts.

About 50% of cloud native environments relied on this tool, and yet for the last several years it was maintained solely by one or two people working in their free time.

What’s the Recommended Replacement?

Gateway API (Official Recommendation)

The official recommendation from Kubernetes SIG Network is to migrate to the Gateway API — considered the modern, persona-driven replacement for the older Ingress resource. Key advantages include expressive routing with first-class support for filters, rewrites, timeouts, and retries; separation of concerns between platform admins and app teams; and native L4/L7 routing for HTTP, gRPC, TCP, and UDP.

Gateway API uses new resource types instead of the old Ingress object:

# Gateway API example (replaces Ingress)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 80

Actively Maintained Alternatives

If you’re not ready for Gateway API, these controllers are actively maintained:

Key Takeaway

The Ingress API spec itself is NOT deprecated — only the community ingress-nginx controller is retired. You can still use kind: Ingress resources with any of the alternative controllers above, or migrate fully to the modern Gateway API.

If you’re running ingress-nginx in production today, check your clusters with:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

And start planning your migration now.