✅ Understanding Kubernetes Ingress, Ingress Controllers, Envoy, and HTTPProxy

A complete guide for backend engineers and cloud architects

Modern Kubernetes applications require secure, scalable, and intelligent ways to expose HTTP/HTTPS traffic. But many developers are confused about:

What Ingress actually does
What an Ingress Controller is
Why we need Envoy or NGINX
What Contour is
What HTTPProxy does
Where routing and rate limiting actually happen

This post explains everything clearly and practically with diagrams.

✅ 1. What Is Ingress in Kubernetes? (Important Clarification)

Ingress is NOT a router.
Ingress is NOT a proxy.
Ingress does NOT handle traffic.

Ingress is only a Kubernetes API resource (YAML) that defines routing rules.

Example:


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ing
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /orders
        backend:
          service:
            name: orders-service
            port:
              number: 80

This YAML simply tells Kubernetes:

✅ which host you want
✅ which path you want
✅ which service requests should go to

BUT nothing happens unless there is an Ingress Controller.

✅ 2. What Exactly Is an Ingress Controller?

An Ingress Controller is the actual logic + control plane that:

✅ Watches Ingress YAML
✅ Translates rules into proxy configuration
✅ Programs a real L7 proxy such as Envoy or NGINX
✅ Handles dynamic updates

The Ingress Controller is the brain that interprets the YAML.

✅ 3. What Actually Handles the Traffic? → The Proxy (Data Plane)

The actual routing, TLS termination, load balancing, retries, timeouts, and rate limiting are done by:

✅ Envoy
✅ NGINX
✅ HAProxy
✅ Traefik
✅ AWS ALB
✅ Istio Envoy sidecars

Ingress Controller reads rules → configures proxy → proxy routes traffic.

✅ ✅ 4. Most Important Diagram


Ingress (YAML)
       │
       ▼
Ingress Controller
       │
       ├── NGINX Ingress Controller → NGINX Proxy
       ├── Contour Ingress Controller → Envoy Proxy
       ├── HAProxy Ingress Controller → HAProxy Proxy
       ├── Traefik Controller → Traefik Proxy
       ├── AWS ALB Ingress Controller → AWS ALB (External Load Balancer)
       └── Istio Gateway Controller → Envoy (Mesh Gateway)

✅ This shows the exact relationship between the components
✅ Developers will instantly understand the architecture

✅ 5. Where Does Routing Actually Happen?

✅ Routing happens in the PROXY (data plane):

Envoy
NGINX
HAProxy
Traefik
ALB

NOT in Ingress.
NOT in HTTPProxy.
NOT in Contour.

Only the proxy handles live HTTP traffic.

✅ 6. Where Does Rate Limiting Happen?

✅ Rate limiting happens inside the proxy (Envoy/NGINX/HAProxy) — not in Ingress or Contour.

Example:

HTTPProxy defines rate limit rules
Contour translates them
Envoy enforces them

Flow:


HTTPProxy (define rules)
        ↓
Contour (configure Envoy)
        ↓
Envoy Proxy (rate limiting executed)

✅ 7. Understanding Contour + HTTPProxy + Envoy

Contour is a specialized Ingress Controller.

✅ Contour (control plane) reads Ingress and HTTPProxy.
✅ Envoy (data plane) executes routing, TLS, rate limiting.
✅ HTTPProxy (CRD) defines advanced routing not possible in Ingress.

✅ What HTTPProxy adds:

Canary deployments
Blue/green
Weighted traffic
Header-based routing
Path rewrites
Multi-team safe delegation
Retry policies
Advanced TLS
Rate limiting

HTTPProxy = advanced routing spec
Contour = translates spec
Envoy = enforces routing

✅ 8. A Complete Request Path (Corrected & Accurate)


Client Request (HTTPS)
        ↓
External Load Balancer (AWS NLB/ELB)
        ↓
Contour Ingress Controller 
        ↓ (reads Ingress/HTTPProxy and configures Envoy)
Envoy Data Plane (Actual routing + TLS + rate limiting)
        ↓
Service (ClusterIP)
        ↓
Pods

✅ Routing = Envoy
✅ TLS termination = Envoy
✅ Rate limiting = Envoy
✅ Mirroring/canary = Envoy
✅ Logging/metrics/tracing = Envoy

✅ 9. Ingress vs HTTPProxy (Contour CRD)

Feature	Ingress	HTTPProxy
Basic routing	✅	✅
TLS	✅	✅ Advanced
Weighted traffic	❌	✅
Traffic mirroring	❌	✅
Canary/blue-green	❌	✅
Delegation	❌	✅
Path rewrite	⚠️ Limited	✅ Strong
Header routing	⚠️ Limited	✅ Advanced
Rate limiting	❌	✅ (Envoy)
Retry, timeout	❌	✅
Multi-team routing	❌	✅

✅ Ingress = simple
✅ HTTPProxy = enterprise-grade

✅ 10. Choosing the Right Ingress Controller (Practical Guide)

✅ Use NGINX Ingress when:

Apps are simple
You only need basic routing
You prefer NGINX ecosystem

✅ Use Contour + Envoy when:

You need performance
You need rate limiting
You need canary/blue-green
You want safer config reloads
You want Envoy’s HTTP/2/gRPC support

✅ Use AWS ALB Ingress Controller when:

Running on EKS
You want WAF/Shield
You want direct L7 LB without proxies in cluster

✅ Use Istio Gateway when:

You are using service mesh
Need mTLS, tracing, advanced policies

✅ 11. Summary

Kubernetes Ingress networking can be confusing, but the model is actually simple:

✅ Ingress defines rules
✅ Ingress Controller interprets rules
✅ Proxy (Envoy/NGINX/HAProxy/Traefik/ALB) executes routing
✅ HTTPProxy provides advanced routing features when using Contour

Final mental model:


Ingress or HTTPProxy → Controller → Proxy → Service → Pod

If you remember only ONE thing:

✅ Ingress defines. Envoy executes. Contour translates.

The Backend Engineer’s Journal