Bayangkan Anda mengelola sebuah cluster Kubernetes dengan sepuluh aplikasi berbeda. Jika setiap aplikasi butuh akses publik dan Anda membuatkan satu Service bertipe LoadBalancer untuk masing-masing, Anda akan berakhir dengan sepuluh IP publik, sepuluh biaya load balancer dari cloud provider, dan sepuluh titik konfigurasi yang terpisah. Selain mahal, ini juga sulit dikelola.

Di sinilah Ingress Controller berperan. Alih-alih membuka satu LoadBalancer untuk setiap Service, Anda cukup membuka satu pintu masuk saja — satu IP, satu titik trafik HTTP/HTTPS — lalu mengatur ke mana trafik itu diarahkan berdasarkan hostname atau path URL. Bagi siapa pun yang mengelola aplikasi web di atas Kubernetes, baik untuk keperluan produksi maupun homelab pribadi, memahami konsep ini adalah keterampilan dasar yang wajib dikuasai.

Artikel ini akan membahas tuntas apa itu Ingress Controller, bagaimana cara kerjanya, cara mengonfigurasinya dengan contoh nyata, kesalahan umum yang sering terjadi, serta catatan penting terkait perubahan besar yang tengah berlangsung di ekosistem Ingress pada tahun 2026.

Pembahasan Utama

Apa Itu Ingress di Kubernetes?

Ingress adalah resource API Kubernetes (networking.k8s.io/v1, kind Ingress) yang mendefinisikan aturan routing trafik HTTP/HTTPS dari luar cluster menuju Service-Service di dalamnya. Ingress sendiri hanyalah sekumpulan aturan — semacam “peta jalan”. Yang benar-benar mengeksekusi aturan tersebut, membaca konfigurasi, dan meneruskan trafik adalah komponen terpisah bernama Ingress Controller.

Analoginya seperti gedung apartemen. Ingress adalah daftar nama penghuni beserta nomor kamarnya yang ditempel di lobi. Ingress Controller adalah satpam di pintu depan yang membaca daftar itu dan mengarahkan tamu ke kamar yang benar. Tanpa satpam, daftar nama itu hanya kertas — tidak berfungsi apa-apa.

Kenapa Bukan LoadBalancer Biasa?

Service bertipe LoadBalancer memang bisa mengekspos aplikasi ke internet, tapi setiap Service butuh IP publik dan resource load balancer sendiri dari cloud provider. Ini boros, terutama saat aplikasi bertambah banyak.

Dengan Ingress Controller, Anda hanya perlu satu Service LoadBalancer (atau bahkan cukup NodePort di lingkungan on-premise), yang menjadi gerbang tunggal untuk seluruh cluster. Ingress Controller di baliknya yang mengurus logika “trafik dengan host A masuk ke Service A, trafik dengan path /admin masuk ke Service B”, dan seterusnya.

Keuntungan utamanya:

• Efisiensi biaya — cukup satu load balancer eksternal untuk banyak aplikasi.
• Routing berbasis host dan path — satu domain bisa melayani banyak aplikasi berbeda.
• TLS terpusat — sertifikat SSL/TLS bisa dikelola di satu titik, bukan di setiap aplikasi.
• Fitur tambahan — rewrite URL, rate limiting, load balancing algorithm, autentikasi dasar, dan sebagainya, tergantung controller yang dipakai.

Bagaimana Cara Kerjanya?

Alur sederhananya seperti ini:

1. Klien mengakses domain, misalnya app.contoh.com.
2. DNS mengarahkan ke IP publik yang menempel pada Service Ingress Controller.
3. Ingress Controller menerima request, membaca aturan pada resource Ingress yang sudah dibuat.
4. Berdasarkan hostname atau path pada request, controller meneruskan trafik ke Service backend yang sesuai.
5. Service backend meneruskan ke Pod aplikasi.

Satu hal penting: resource Ingress tidak akan berfungsi tanpa Ingress Controller yang berjalan di cluster. Banyak pemula bingung kenapa Ingress yang sudah dibuat tidak mendapat IP atau tidak merespons — penyebabnya sering kali karena controller-nya belum ter-install sama sekali.

Contoh Konfigurasi Ingress

Berikut contoh manifest Ingress dasar menggunakan salah satu implementasi berbasis NGINX, dengan dua aplikasi berbeda yang diakses lewat path berbeda pada satu domain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: app.contoh.com
      http:
        paths:
          - path: /toko
            pathType: Prefix
            backend:
              service:
                name: service-toko
                port:
                  number: 80
          - path: /blog
            pathType: Prefix
            backend:
              service:
                name: service-blog
                port:
                  number: 80

Penjelasan bagian penting:

• ingressClassName: nginx — menentukan controller mana yang menangani resource Ingress ini. Wajib diisi jika di cluster Anda ada lebih dari satu controller.
• host — domain yang menjadi pintu masuk.
• path dan pathType — menentukan segmen URL yang diarahkan ke Service tertentu. Prefix berarti semua URL yang diawali path tersebut akan cocok.
• annotations — konfigurasi tambahan yang sifatnya spesifik untuk masing-masing controller (tidak portable antar-controller berbeda).

Untuk menambahkan HTTPS, tinggal tambahkan blok tls:

  tls:
    - hosts:
        - app.contoh.com
      secretName: app-tls-secret

app-tls-secret adalah Kubernetes Secret berisi sertifikat TLS, yang biasanya dikelola otomatis menggunakan cert-manager.

Catatan Penting: Perubahan Besar di Ekosistem Ingress (2026)

Sebelum Anda menyalin konfigurasi di atas ke produksi, ada satu hal krusial yang wajib diketahui: proyek komunitas ingress-nginx — controller berbasis NGINX yang paling populer dan menjadi bawaan di banyak distribusi Kubernetes — resmi memasuki masa pensiun mulai Maret 2026. Setelah tanggal tersebut, proyek ini tidak lagi menerima rilis baru, perbaikan bug, maupun patch keamanan. Deployment yang sudah berjalan tidak langsung rusak, tapi menjalankannya di produksi tanpa patch keamanan jangka panjang adalah risiko yang semakin membesar seiring waktu.

Beberapa hal yang perlu dibedakan agar tidak salah paham:

• API Ingress (networking.k8s.io/v1) itu sendiri tidak dihapus — hanya sudah dianggap “feature-frozen” alias tidak dikembangkan lebih lanjut.
• ingress-nginx (proyek komunitas SIG-Network) adalah yang dipensiunkan.
• NGINX Ingress Controller (NIC), proyek terpisah yang dikelola F5, tetap aktif dikembangkan — jangan sampai tertukar namanya.
• Pengganti jangka panjang yang direkomendasikan komunitas Kubernetes adalah Gateway API, standar baru untuk routing trafik yang lebih portabel dan tidak bergantung annotation spesifik-controller.

Untuk proyek baru, pertimbangkan langsung menggunakan controller yang masih aktif dan mendukung migrasi ke Gateway API, seperti Traefik, Kong, HAProxy Ingress Controller, NGINX Ingress Controller (F5), atau Cilium. Untuk cluster lama yang masih memakai ingress-nginx, mulailah rencanakan migrasi sekarang — jangan menunggu sampai terjadi insiden keamanan.

Studi Kasus Sederhana

Sebuah tim kecil mengelola dua aplikasi: toko online dan blog perusahaan. Awalnya mereka membuat dua Service LoadBalancer terpisah, sehingga mendapat dua IP publik dan dua tagihan load balancer dari cloud provider setiap bulan.

Setelah beralih ke Ingress Controller:

• Kedua aplikasi digabung di satu domain: app.contoh.com/toko dan app.contoh.com/blog.
• Hanya satu Service LoadBalancer yang dibutuhkan, sebagai gerbang untuk Ingress Controller.
• Biaya infrastruktur bulanan turun karena hanya satu load balancer eksternal yang dibayar.
• Sertifikat TLS dikelola otomatis lewat cert-manager, tidak perlu diatur manual di setiap aplikasi.

Implementasi Langkah demi Langkah

1. Install Ingress Controller. Contoh dengan Helm: helm install nginx-ingress ingress-nginx/ingress-nginx \ --namespace ingress-nginx --create-namespace (Gunakan controller yang masih aktif dipelihara jika ini instalasi baru.)
2. Pastikan Service Controller sudah mendapat External IP. kubectl get svc -n ingress-nginx
3. Arahkan DNS domain Anda ke External IP tersebut.
4. Buat resource Ingress seperti contoh manifest di atas, sesuaikan host, path, dan nama Service backend.
5. Terapkan manifest: kubectl apply -f app-ingress.yaml
6. Verifikasi routing dengan mengakses masing-masing path dari browser atau curl.

Kesalahan yang Sering Terjadi

1. Membuat Ingress tanpa meng-install Ingress Controller. Penyebab: mengira resource Ingress otomatis berfungsi begitu dibuat. Dampak: request tidak pernah sampai ke aplikasi, External IP tidak pernah muncul. Solusi: pastikan controller sudah berjalan (kubectl get pods -n <namespace-controller>) sebelum membuat resource Ingress.

2. Lupa mengisi ingressClassName saat ada lebih dari satu controller. Penyebab: mengasumsikan hanya ada satu controller default di cluster. Dampak: Ingress “menempel” ke controller yang salah, atau tidak diproses sama sekali. Solusi: selalu eksplisit mengisi ingressClassName.

3. Menyalahgunakan annotation snippet untuk konfigurasi kompleks. Penyebab: fitur bawaan controller dianggap kurang fleksibel. Dampak: celah keamanan, karena snippet memungkinkan injeksi konfigurasi NGINX mentah — ini salah satu alasan utama proyek ingress-nginx dipensiunkan. Solusi: gunakan annotation resmi yang tersedia, atau pertimbangkan Gateway API untuk kebutuhan routing lanjutan.

4. Path matching yang salah antara Prefix dan Exact. Penyebab: tidak memahami perbedaan pathType. Dampak: request tidak sampai ke Service yang seharusnya, atau justru “menabrak” path aplikasi lain. Solusi: uji setiap path secara eksplisit setelah deployment, jangan hanya mengandalkan asumsi.

5. Tidak memperbarui informasi saat memilih controller. Penyebab: mengikuti tutorial lama tanpa mengecek status proyek terkini. Dampak: memasang controller yang sudah tidak menerima patch keamanan. Solusi: cek status pemeliharaan resmi sebelum memutuskan controller untuk produksi.

Tips dan Rekomendasi

• Gunakan cert-manager untuk otomasi sertifikat TLS, jangan kelola manual.
• Terapkan resource limits pada Pod Ingress Controller agar tidak menjadi bottleneck saat trafik tinggi.
• Aktifkan logging dan metrics (Prometheus) dari controller untuk memantau latensi dan error rate.
• Untuk kebutuhan routing lanjutan (header-based routing, traffic splitting/canary), pertimbangkan migrasi bertahap ke Gateway API alih-alih menumpuk annotation.
• Pisahkan Ingress untuk lingkungan staging dan produksi agar kesalahan konfigurasi tidak langsung berdampak ke pengguna akhir.

Kesimpulan

Ingress Controller adalah komponen kunci yang membuat pengelolaan akses aplikasi di Kubernetes menjadi efisien: satu titik masuk untuk banyak aplikasi, routing berbasis host maupun path, serta pengelolaan TLS yang terpusat. Namun ekosistemnya sedang berubah signifikan — proyek ingress-nginx yang selama ini menjadi pilihan populer kini memasuki masa pensiun, sementara Gateway API menjadi standar baru yang direkomendasikan komunitas Kubernetes.

Poin penting yang perlu diingat:

• Ingress hanyalah aturan; Ingress Controller yang mengeksekusinya.
• Satu load balancer eksternal bisa melayani banyak aplikasi lewat satu Ingress Controller.
• Perhatikan ingressClassName dan pathType agar routing berjalan sesuai rencana.
• Untuk proyek baru, evaluasi controller yang masih aktif dipelihara atau mulai rencanakan migrasi ke Gateway API.

Bagaimana pengalaman Anda mengelola trafik di Kubernetes? Apakah masih memakai ingress-nginx, atau sudah mulai migrasi ke controller lain?

---

Frequently Asked Questions (FAQ)

Pertanyaan: Apa perbedaan Ingress dan Ingress Controller? Jawaban: Ingress adalah resource API berisi aturan routing, sedangkan Ingress Controller adalah komponen yang benar-benar membaca dan mengeksekusi aturan tersebut. Tanpa controller, resource Ingress tidak berfungsi.

Pertanyaan: Apakah Nginx Ingress masih aman digunakan pada tahun 2026? Jawaban: Proyek komunitas ingress-nginx sudah memasuki masa pensiun sejak Maret 2026 dan tidak lagi menerima patch keamanan. Untuk proyek baru, sebaiknya pilih controller lain yang masih aktif dipelihara, seperti NGINX Ingress Controller (F5), Traefik, atau migrasi ke Gateway API.

Pertanyaan: Apakah Ingress bisa menangani HTTPS? Jawaban: Bisa, dengan menambahkan blok tls pada manifest Ingress dan Secret berisi sertifikat. Otomasi sertifikat biasanya menggunakan cert-manager.

Pertanyaan: Kenapa Ingress saya tidak mendapat External IP? Jawaban: Biasanya karena Ingress Controller belum ter-install di cluster, atau Service controller belum bertipe LoadBalancer yang didukung oleh environment Anda.

Pertanyaan: Apa itu Gateway API dan apakah harus langsung migrasi? Jawaban: Gateway API adalah standar routing generasi baru di Kubernetes yang lebih portabel dan tidak bergantung pada annotation spesifik-controller. Migrasi tidak harus dilakukan mendadak, tapi disarankan mulai direncanakan, terutama jika saat ini masih memakai ingress-nginx.

---

Sudah pernah mengonfigurasi Ingress Controller sendiri di cluster Anda? Ceritakan pengalaman Anda di kolom komentar

apakah masih memakai ingress-nginx, atau sudah mulai mencoba Gateway API? Jangan lupa bagikan artikel ini ke rekan tim atau komunitas DevOps Anda, dan jelajahi artikel-artikel lain seputar Kubernetes, Linux, dan infrastruktur cloud di website ini agar tidak ketinggalan update konten terbaru.