Ingress #

Service tipe LoadBalancer bekerja dengan baik untuk expose satu service ke internet, tapi jika kamu punya dua puluh microservice yang perlu di-expose, kamu tidak mau membayar dua puluh cloud load balancer. Ingress menyelesaikan masalah ini: satu entry point untuk semua traffic HTTP/HTTPS dari luar cluster, dengan routing berbasis URL path dan hostname ke Service yang tepat di dalam cluster.

Masalah yang Diselesaikan Ingress #

Tanpa Ingress — setiap Service butuh LoadBalancer sendiri:

  api.example.com        → LoadBalancer 1 ($) → Service: api
  auth.example.com       → LoadBalancer 2 ($) → Service: auth
  dashboard.example.com  → LoadBalancer 3 ($) → Service: dashboard
  ...20 service = 20 load balancer = $$$

Dengan Ingress — satu load balancer untuk semua:

  example.com/api        ─┐
  example.com/auth       ─┤→ LoadBalancer → Ingress → routing → Service yang tepat
  dashboard.example.com  ─┘

  1 load balancer = jauh lebih hemat

Komponen Ingress #

Ada dua resource yang bekerja bersama:

Ingress resource — manifest yang mendefinisikan rules routing. Ia hanyalah konfigurasi — tidak melakukan apa-apa sendiri.

Ingress Controller — program yang berjalan di cluster dan mengimplementasikan rules di Ingress resource. Kubernetes tidak menyertakan Ingress Controller secara default — kamu harus install sendiri.

Hubungan keduanya:

Ingress Resource (konfigurasi):
  "Kirim traffic ke example.com/api ke Service api:80"
  "Kirim traffic ke example.com/auth ke Service auth:80"

Ingress Controller (implementasi):
  Membaca rules dari Ingress resource
  Mengonfigurasi reverse proxy (nginx, haproxy, envoy, dll)
  Meneruskan traffic sesuai rules

Struktur Manifest Ingress #

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /   # annotasi spesifik controller
spec:
  ingressClassName: nginx                           # tentukan Ingress Controller mana

  # TLS termination
  tls:
  - hosts:
    - api.example.com
    - app.example.com
    secretName: example-tls-secret   # Secret berisi TLS certificate

  rules:
  # Host-based routing
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

  # Path-based routing
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /auth
        pathType: Prefix
        backend:
          service:
            name: auth-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

Path Types #

pathType menentukan cara path dicocokkan:

Exact:
  path: /api/users
  → Hanya cocok dengan /api/users persis
  → /api/users/123 TIDAK cocok

Prefix:
  path: /api
  → Cocok dengan /api, /api/users, /api/users/123
  → Semua yang diawali dengan /api

ImplementationSpecific:
  → Diserahkan ke Ingress Controller
  → Perilaku bisa berbeda antar controller

Urutan matching: Ingress Controller biasanya memilih rule yang paling spesifik. Path yang lebih panjang atau Exact diprioritaskan dari Prefix yang lebih pendek.

TLS Termination #

Ingress bisa menangani TLS termination — koneksi HTTPS dari client diakhiri di Ingress, lalu traffic diteruskan ke Service internal via HTTP biasa.

# Buat Secret untuk TLS certificate
kubectl create secret tls example-tls-secret \
  --cert=path/to/cert.pem \
  --key=path/to/key.pem \
  -n production

# Ingress dengan TLS
spec:
  tls:
  - hosts:
    - api.example.com
    secretName: example-tls-secret
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

Alur traffic dengan TLS termination:

Client → HTTPS (443) → Ingress Controller (TLS terminated)
                     → HTTP (80) → Service → Pod

Untuk manajemen certificate otomatis, integrasikan dengan cert-manager yang bisa otomatis issue dan renew certificate dari Let’s Encrypt atau CA lain.

Pilihan Ingress Controller #

Berbagai Ingress Controller tersedia, masing-masing dengan karakteristik berbeda:

NGINX Ingress Controller (paling populer):
  ✓ Mature, dokumentasi lengkap, komunitas besar
  ✓ Fitur lengkap: rate limiting, auth, rewrite, mirror
  ✓ Dua versi: kubernetes/ingress-nginx (komunitas) dan nginx/kubernetes-ingress (NGINX Inc)
  ✗ Tidak se-efisien layer 4 load balancing untuk traffic sangat tinggi

Traefik:
  ✓ Auto-discovery: detect Ingress/Service otomatis tanpa reload
  ✓ Dashboard built-in
  ✓ Mendukung TCP/UDP selain HTTP
  ✓ Cocok untuk microservice yang sering berubah

AWS ALB Ingress Controller:
  ✓ Native integrasi dengan AWS Application Load Balancer
  ✓ Ideal untuk cluster di EKS
  ✗ Vendor-specific, tidak portable ke cloud lain

GCE Ingress Controller:
  ✓ Otomatis dibuat di GKE
  ✓ Native integrasi dengan Google Cloud Load Balancing
  ✗ Khusus GKE

Istio Gateway:
  ✓ Terintegrasi dengan service mesh
  ✓ mTLS, observability, traffic management canggih
  ✗ Kompleks, overhead resource tinggi

Annotations: Fitur Spesifik Controller #

Fitur canggih Ingress seperti rate limiting, authentication, dan custom header biasanya dikonfigurasi via annotations yang spesifik untuk setiap controller:

metadata:
  annotations:
    # NGINX: rate limiting
    nginx.ingress.kubernetes.io/limit-rps: "100"

    # NGINX: timeout
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"

    # NGINX: basic authentication
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: basic-auth-secret

    # NGINX: CORS
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "https://app.example.com"

    # NGINX: redirect HTTP ke HTTPS
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

    # Traefik: middleware
    traefik.ingress.kubernetes.io/router.middlewares: production-ratelimit@kubernetescrd

Ingress vs Gateway API #

Kubernetes Gateway API adalah penerus Ingress yang lebih ekspresif dan powerful. Mulai mature di Kubernetes 1.24+:

Ingress:
  → Simple, satu resource untuk semua rules
  → Keterbatasan: tidak bisa express semua routing scenario
  → Fitur canggih hanya via annotations (non-standard)

Gateway API:
  → Lebih ekspresif: GatewayClass, Gateway, HTTPRoute, TCPRoute
  → Mendukung traffic splitting, header-based routing, weighted routing
  → Separation of concerns: ops mengelola Gateway, dev mengelola HTTPRoute
  → Standar yang lebih terdefinisi antar controller

Untuk cluster baru, pertimbangkan Gateway API jika controller yang kamu pilih sudah mendukungnya. Ingress masih tetap relevan dan tidak akan dihapus.

Ringkasan #

  • Ingress = satu entry point untuk semua Service HTTP/HTTPS — menggantikan banyak LoadBalancer dengan satu, menghemat biaya dan kompleksitas.
  • Dua komponen: Ingress resource dan Ingress Controller — resource adalah konfigurasi, controller adalah implementasi; harus install controller sendiri karena tidak ada default.
  • Host-based dan path-based routing — bisa route berdasarkan hostname (api.example.com) atau path (/api, /auth); Exact lebih spesifik dari Prefix.
  • TLS termination di Ingress — sertifikat dikelola di level Ingress, traffic internal ke Service bisa plain HTTP; gunakan cert-manager untuk manajemen sertifikat otomatis.
  • NGINX Ingress adalah pilihan paling umum — mature, fitur lengkap, komunitas besar; Traefik untuk yang butuh auto-discovery; ALB/GCE untuk integrasi native cloud.
  • Annotations untuk fitur spesifik controller — rate limiting, auth, CORS, timeout dikonfigurasi via annotations; non-standard tapi praktis.

← Sebelumnya: DNS & Service Discovery   Berikutnya: Network Policy →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact