Ingress Controller Comparison #

Memilih Ingress Controller adalah salah satu keputusan arsitektur awal yang dampaknya terasa jangka panjang. Mengganti Ingress Controller di cluster yang sudah berjalan bukan pekerjaan trivial — kamu perlu migrasi semua Ingress resource, menyesuaikan annotations, dan menguji ulang semua routing. Artikel ini memberikan gambaran yang cukup detail untuk membuat keputusan yang tepat dari awal.

Kandidat Utama #

NGINX Ingress Controller (komunitas) #

Ini adalah kubernetes/ingress-nginx — proyek Kubernetes resmi yang menggunakan NGINX sebagai reverse proxy.

kubernetes/ingress-nginx:

  Cara kerja:
    Single NGINX process per controller Pod
    Konfigurasi di-generate ulang dan NGINX di-reload saat ada perubahan Ingress

  Kekuatan:
  ✓ Paling banyak digunakan — dokumentasi dan contoh berlimpah
  ✓ Fitur NGINX lengkap via annotations: rate limit, auth, rewrite, mirror
  ✓ Support WebSocket secara native
  ✓ Aktif dikembangkan, update cepat

  Kelemahan:
  ✗ NGINX reload saat ada perubahan konfigurasi → brief period tanpa traffic
    (reload graceful, tapi ada jeda untuk koneksi baru)
  ✗ Konfigurasi rumit via annotations (tidak ada type safety)
  ✗ Satu controller menangani semua namespace = bottleneck di cluster besar

  Cocok untuk:
  ✓ Hampir semua kasus umum
  ✓ Tim yang familiar dengan NGINX
  ✓ Cluster on-premise atau hybrid

Traefik #

Proxy modern yang dirancang untuk dynamic environment seperti Kubernetes.

Traefik:

  Cara kerja:
    Watch API Server untuk perubahan Ingress/Service secara real-time
    Konfigurasi di-update tanpa reload (hot configuration)

  Kekuatan:
  ✓ Tidak ada reload → zero-downtime saat konfigurasi berubah
  ✓ Dashboard built-in yang informatif
  ✓ Mendukung TCP dan UDP routing (tidak hanya HTTP)
  ✓ CRD sendiri (IngressRoute) yang lebih ekspresif dari annotations
  ✓ Otomatis mendapat certificate dari Let's Encrypt
  ✓ Mendukung plugin ecosystem

  Kelemahan:
  ✗ Resource lebih besar dari NGINX untuk traffic rendah
  ✗ Dua cara konfigurasi: Ingress standard + IngressRoute CRD — bisa membingungkan
  ✗ Performa sedikit di bawah NGINX untuk throughput sangat tinggi

  Cocok untuk:
  ✓ Environment yang sering berubah konfigurasi
  ✓ Tim yang butuh dashboard visibility
  ✓ Butuh TCP/UDP selain HTTP
  ✓ Multi-cloud atau on-premise dengan Let's Encrypt

HAProxy Ingress #

Berbasis HAProxy — terkenal sebagai proxy dengan performa dan reliability tinggi di industri.

HAProxy Ingress:

  Kekuatan:
  ✓ Performa sangat tinggi, latensi konsisten
  ✓ Reload tanpa drop koneksi via HAProxy runtime API
  ✓ Fine-grained traffic control
  ✓ Session persistence yang baik

  Kelemahan:
  ✗ Komunitas lebih kecil dari NGINX/Traefik
  ✗ Konfigurasi lebih kompleks
  ✗ Dokumentasi Kubernetes-spesifik tidak selengkap NGINX

  Cocok untuk:
  ✓ Workload dengan kebutuhan session persistence yang tinggi
  ✓ Tim yang sudah familiar dengan HAProxy

AWS ALB Ingress Controller (AWS Load Balancer Controller) #

Membuat AWS Application Load Balancer untuk setiap Ingress resource — bukan proxy in-cluster.

AWS Load Balancer Controller:

  Cara kerja:
    Setiap Ingress → provisioning ALB di AWS
    Traffic tidak melalui in-cluster proxy — langsung ke Pod via target group

  Kekuatan:
  ✓ Native AWS integration — WAF, Shield, ACM certificate otomatis
  ✓ Tidak ada in-cluster proxy = lebih sedikit komponen yang bisa gagal
  ✓ Auto-scaling ALB sesuai traffic
  ✓ Integrasi native dengan IAM, VPC, Security Group

  Kelemahan:
  ✗ Setiap Ingress = satu ALB = biaya per Ingress
    (bisa mahal jika banyak Ingress; gunakan IngressGroup untuk share ALB)
  ✗ Hanya untuk EKS/AWS
  ✗ Fitur routing lebih terbatas dari NGINX

  Cocok untuk:
  ✓ Cluster di EKS dengan kebutuhan native AWS integration
  ✓ Butuh WAF atau Shield untuk perlindungan DDoS
  ✓ Audit requirement yang mengharuskan traffic melalui AWS networking

GKE Ingress (GCE Ingress Controller) #

Otomatis tersedia di GKE, membuat Google Cloud Load Balancer.

GKE Ingress:

  Kekuatan:
  ✓ Zero setup di GKE — langsung tersedia
  ✓ Native integrasi dengan Google Cloud CDN, Cloud Armor (WAF)
  ✓ Global load balancing dengan anycast IP
  ✓ Certificate Manager integrasi

  Kelemahan:
  ✗ Khusus GKE
  ✗ Lebih lambat merespons perubahan routing (provisioning via GCP API)
  ✗ Biaya per backend config bisa bertambah

  Cocok untuk:
  ✓ Cluster di GKE yang butuh simplicity
  ✓ Butuh Google Cloud CDN atau Cloud Armor

Decision Tree: Pilih Ingress Controller #

Cluster di cloud mana?

AWS EKS:
  └─ Butuh native WAF/Shield?
       └─ Ya  → AWS Load Balancer Controller
       └─ Tidak → NGINX atau Traefik (lebih fleksibel)

GKE:
  └─ Butuh Google CDN atau Cloud Armor?
       └─ Ya  → GKE Ingress (bawaan)
       └─ Tidak → NGINX atau Traefik

On-premise atau multi-cloud:
  └─ Sering ganti konfigurasi tanpa downtime?
       └─ Ya  → Traefik
       └─ Tidak → NGINX (lebih familiar, dokumentasi lebih banyak)
  └─ Butuh performa maksimal dengan session persistence?
       └─ → HAProxy

Semua kasus general (tidak ada requirement khusus):
  → NGINX Ingress Controller (kubernetes/ingress-nginx)
    paling aman karena komunitas terbesar, contoh terbanyak

Mengoperasikan Multi-Controller #

Di cluster besar, bisa ada lebih dari satu Ingress Controller — misalnya NGINX untuk internal service, dan AWS ALB untuk public-facing service:

# Ingress yang menggunakan NGINX controller
spec:
  ingressClassName: nginx     # ← pilih controller via IngressClass

---
# Ingress yang menggunakan ALB controller
spec:
  ingressClassName: alb

# IngressClass yang mendefinisikan controller yang tersedia
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"   # jadikan default
spec:
  controller: k8s.io/ingress-nginx

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
spec:
  controller: ingress.k8s.aws/alb

Ringkasan #

NGINX untuk kasus umum — komunitas terbesar, dokumentasi terlengkap, cocok untuk hampir semua skenario kecuali ada requirement khusus.
Traefik untuk zero-downtime config update — hot reload tanpa NGINX reload; unggul untuk environment dinamis dan kebutuhan TCP/UDP.
AWS ALB untuk EKS dengan native AWS integration — WAF, Shield, ACM certificate otomatis; gunakan IngressGroup untuk share satu ALB antara beberapa Ingress.
GKE Ingress untuk simplicity di GKE — zero setup, integrasi native CDN dan Cloud Armor; tidak portable ke luar GKE.
IngressClass untuk multi-controller — sejak Kubernetes 1.18, gunakan spec.ingressClassName untuk memilih controller; satu cluster bisa punya beberapa controller.
Pilih sebelum production, sulit ganti setelah — migrasi Ingress Controller butuh update semua Ingress resource dan annotations; keputusan awal sangat mempengaruhi jangka panjang.

← Sebelumnya: Service Mesh Berikutnya: Network Troubleshooting →