Ingress NGINX Pensiun: Alternatif untuk Kubernetes

Ingress controller adalah komponen yang menerima trafik HTTP dan HTTPS dari luar cluster Kubernetes, lalu meneruskannya ke layanan yang tepat berdasarkan domain dan path. Selama bertahun-tahun, pilihan paling populer untuk tugas ini adalah Ingress NGINX, proyek milik komunitas Kubernetes. Proyek itu kini sudah pensiun.

Taruhannya besar. Ingress controller berdiri di garis depan, menghadap internet. Komponen yang tidak lagi menerima patch keamanan di posisi itu adalah celah yang menunggu ditemukan. Per 4 November 2026, repositori kubernetes/ingress-nginx di GitHub sudah berstatus arsip (hanya baca), dengan rilis chart Helm terakhir tercatat 19 Maret 2026.

Apa yang diumumkan komunitas Kubernetes?

Kronologi singkat

Pada 11 November 2025, SIG Network dan Security Response Committee Kubernetes mengumumkan rencana pensiun Ingress NGINX. Pemeliharaan "sebisanya" dilanjutkan sampai Maret 2026. Setelah itu, menurut pengumuman, tidak ada lagi rilis, perbaikan bug, atau pembaruan untuk kerentanan keamanan yang mungkin ditemukan. Repositori GitHub dijadikan hanya-baca dan dibiarkan tersedia sebagai referensi.

Pada 29 Januari 2026, Steering Committee dan Security Response Committee merilis pernyataan bersama yang lebih keras nadanya. Mereka menyebut Ingress NGINX sebagai infrastruktur penting bagi sekitar setengah lingkungan cloud native, mengutip riset internal Datadog, dan menegaskan bahwa bertahan setelah pensiun membuat pengguna rentan diserang.

Pada 20 Maret 2026, SIG Network merilis Ingress2Gateway 1.0, alat bantu migrasi dari Ingress ke Gateway API yang kini mendukung lebih dari 30 anotasi Ingress NGINX yang umum.

Kenapa proyek sebesar ini dipensiunkan?

Pengumuman resmi menyebut dua alasan. Pertama, kekurangan pengelola: selama bertahun-tahun proyek ini dikerjakan hanya oleh satu atau dua orang di waktu luang. Kedua, utang teknis. Fleksibilitas yang dulu disukai, seperti anotasi "snippets" yang memungkinkan menyisipkan konfigurasi NGINX apa pun, kini dianggap celah keamanan serius. Penggantinya yang direncanakan, InGate, juga tidak berkembang cukup matang dan ikut dipensiunkan.

Perlu dicatat, yang pensiun adalah ingress-nginx milik komunitas Kubernetes. F5 NGINX Ingress Controller (repositori nginx/kubernetes-ingress) adalah proyek terpisah dan tetap aktif. Namanya mirip, tapi anotasi dan konfigurasinya berbeda.

Apa saja pilihan penggantinya?

Ada dua arah besar. Arah pertama adalah Gateway API, API resmi Kubernetes generasi baru yang dirancang sebagai pengganti Ingress. Per 4 November 2026, rilis terbarunya di GitHub adalah v1.7.0 (29 Oktober 2026). Gateway API memisahkan peran: tim infrastruktur mengelola Gateway, tim aplikasi mengelola HTTPRoute. Arah kedua adalah tetap memakai API Ingress dengan ingress controller lain, yang perubahannya lebih kecil dalam jangka pendek.

Daftar implementasi Gateway API yang lengkap dan status konformansinya ada di situs resmi Gateway API. Pernyataan komunitas menegaskan satu hal penting: tidak ada alternatif yang benar-benar pengganti langsung. Semua butuh perencanaan dan pengujian.

Kapan memilih Gateway API, kapan tetap di Ingress?

Pilih Gateway API bila cluster akan dipakai jangka panjang, ada beberapa tim yang berbagi gateway, atau kamu memang perlu fitur seperti pembagian trafik berbobot, pencocokan header, dan routing lintas namespace yang rapi. Karena kamu toh harus menulis ulang konfigurasi, migrasi sekali ke arah yang dituju komunitas Kubernetes menghemat pekerjaan di masa depan. Ingress2Gateway bisa menerjemahkan sebagian besar manifest dan memberi peringatan untuk konfigurasi yang tidak bisa diterjemahkan.

Pilih ingress controller lain bila waktumu sempit, manifest Ingress kamu sederhana (host, path, TLS), atau aplikasi dikelola lewat Helm chart pihak ketiga yang baru menyediakan objek Ingress. Ini langkah pengaman yang sah, asalkan kamu tahu bahwa anotasi khusus Ingress NGINX tetap harus diterjemahkan ke format controller baru.

Untuk cluster kecil, misalnya cluster K3s di beberapa VPS, Traefik yang sudah terpasang sering menjadi jalan termudah, karena ia mendukung Ingress sekaligus Gateway API.

Bagaimana urutan migrasi yang aman?

Gambaran umumnya:

1. Inventaris. Daftar semua objek Ingress dan anotasi yang dipakai. Perhatikan khusus snippet, rewrite, regex, dan pengaturan CORS.
2. Terjemahkan. Jalankan ingress2gateway atau petakan manual ke controller pilihan. Catat semua peringatan.
3. Pasang berdampingan. Jalankan controller baru bersama Ingress NGINX dengan IP atau load balancer berbeda.
4. Uji perilaku, bukan hanya YAML. Bandingkan redirect, rewrite, header, dan ukuran unggahan maksimum. Kubernetes juga menerbitkan tulisan tentang perilaku Ingress NGINX yang sering mengejutkan saat migrasi.
5. Pindahkan DNS bertahap, lalu hapus Ingress NGINX setelah trafik stabil.

Selama masa transisi, perlindungan tambahan di depan cluster seperti WAF membantu mengurangi risiko, tapi bukan pengganti pembaruan keamanan.