Kubernetes Gateway API vs Ingress: Mengapa Ia Menggantikan Anotasi

Saya sudah menjalankan trafik lewat Ingress selama bertahun-tahun, dan polanya selalu membusuk dengan cara yang sama. Anda mulai dengan spesifikasi host-dan-path yang bersih, lalu muncul keanehan TLS, lalu rewrite, lalu rate limit, dan enam bulan kemudian manifest Ingress Anda menjadi dinding anotasi khusus controller yang hanya dipahami satu orang di tim. Ingress distandarkan pada 2015 dan spesifikasinya nyaris tidak berubah; setiap fitur di luar routing host dasar harus diselundupkan lewat anotasi yang tidak portabel antar controller.

Gateway API memperbaiki akar penyebab, bukan gejalanya. Ia telah mencapai tonggak stabil v1 dan kini berada di versi 1.5.x, dengan grup API gateway.networking.k8s.io. Waktunya penting: pada 24 Maret 2026, proyek kubernetes/ingress-nginx mencapai akhir masa pakai. Repositorinya bersifat baca-saja, dan tidak akan ada lagi perbaikan bug atau tambalan CVE. Jika Anda menjalankan ingress-nginx hari ini, migrasi bukan lagi sekadar pilihan.

Satu resource yang mencoba melakukan segalanya

Cacat desain inti Ingress adalah satu resource mencampur dua pekerjaan yang sama sekali berbeda. Ia mendeskripsikan di mana trafik masuk ke cluster (load balancer, IP-nya, sertifikat TLS-nya) dan bagaimana trafik dirutekan ke service (host, path, backend) dalam objek yang sama. Di sebagian besar organisasi keduanya dimiliki orang yang berbeda: tim platform atau infrastruktur memiliki edge, dan tim aplikasi memiliki rute mereka sendiri. Ingress memaksa kedua urusan itu ke dalam satu manifest, sehingga entah tim platform menjadi penghambat yang menyetujui setiap perubahan rute, atau tim aplikasi mendapat akses tulis ke edge bersama dan bisa saling merusak.

Gateway API memecah satu resource itu tepat di garis yang sudah diikuti bagan organisasi Anda. Ada tiga resource utama, masing-masing dengan pemilik yang jelas.

• GatewayClass: templat untuk sejenis gateway, terikat pada implementasi controller tertentu. Penyedia infrastruktur atau vendor controller yang memilikinya, dan Anda biasanya memasangnya sekali per cluster.
• Gateway: titik masuk yang sesungguhnya. Ia mendeklarasikan listener (port, protokol, sertifikat TLS) dan rute mana yang boleh menempel. Tim platform atau operator cluster yang memilikinya.
• HTTPRoute: aturan routing, host, path, pencocokan header, rewrite, dan pembagian trafik. Pengembang aplikasi memilikinya di namespace mereka sendiri dan mengirimkannya bersama aplikasi mereka.

Sebuah HTTPRoute menempel ke Gateway melalui field parentRefs, dan Gateway memutuskan lewat aturan allowedRoutes-nya namespace mana yang boleh menempel. Itulah seluruh triknya: tim platform mengunci edge dan TLS sekali, lalu memberi pengembang permukaan swalayan yang aman untuk routing mereka sendiri. Tanpa file bersama, tanpa penghambat review anotasi, tanpa radius ledakan tak sengaja antar tim.

Mengapa anotasi harus pergi

Berikut ide yang sama dalam kode. Di bawah ini manifest ingress-nginx tipikal: beberapa field standar ditambah tumpukan anotasi yang hanya dipahami ingress-nginx. Pindahkan ke Traefik atau HAProxy dan anotasi itu tidak berarti apa-apa.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: api
                port:
                  number: 80

Bobot canary, rewrite, redirect SSL: tidak satu pun dari itu ada di spesifikasi Ingress. Semuanya hidup di anotasi vendor, itulah sebabnya manifest Ingress sebenarnya tidak portabel. Gateway API menarik fitur-fitur itu menjadi field spesifikasi bertipe kelas satu. Berikut HTTPRoute setara dengan rewrite path dan pembagian trafik 20 persen yang diekspresikan secara native.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop-team
spec:
  parentRefs:
    - name: prod-gateway
      namespace: infra
  hostnames:
    - shop.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
      backendRefs:
        - name: api-v1
          port: 80
          weight: 80
        - name: api-v2
          port: 80
          weight: 20

Ingress versus Gateway API sekilas

Jalur migrasi yang tidak butuh perubahan besar sekaligus

Kabar baiknya, Ingress dan Gateway API bisa berjalan berdampingan di cluster yang sama, jadi Anda bermigrasi satu service pada satu waktu. Tim Kubernetes SIG-Network juga merilis ingress2gateway 1.0 pada Maret 2026, sebuah CLI yang membaca resource Ingress Anda yang ada dan menghasilkan manifest Gateway dan HTTPRoute setara, termasuk penerjemahan lebih dari tiga puluh anotasi ingress-nginx umum. Ini titik awal, bukan stempel: selalu tinjau keluarannya.

1. Pasang controller yang konforman (Envoy Gateway, kgateway, Traefik, atau implementasi penyedia cloud) dan GatewayClass-nya bersama controller Ingress Anda yang ada.
2. Minta tim platform membuat satu Gateway dengan listener dan sertifikat TLS Anda, dan atur allowedRoutes ke namespace yang membutuhkannya.
3. Jalankan ingress2gateway pada satu service berisiko rendah untuk menghasilkan HTTPRoute-nya, lalu tinjau dan commit manifest tersebut.
4. Validasi kesetaraan routing: host, path, rewrite, header, dan TLS semua berperilaku sama seperti Ingress lama.
5. Alihkan DNS atau trafik ke Gateway begitu metrik dan SLO cocok, lalu hapus Ingress lama. Ulangi per service.

Haruskah Anda bermigrasi sekarang?

Jika Anda memakai ingress-nginx, ya, dan dengan sedikit urgensi, karena ia tidak lagi menerima tambalan keamanan setelah akhir masa pakainya pada Maret 2026. Jika Anda menjalankan Ingress cloud terkelola atau controller lain yang masih didukung, Anda punya lebih banyak waktu, tetapi arah perjalanannya sudah pasti: spesifikasi Ingress dibekukan dan setiap fitur jaringan baru mendarat di Gateway API. Untuk apa pun yang greenfield, saya tidak akan memulai cluster baru dengan Ingress pada 2026. Mulailah dengan Gateway API, tetapkan batas peran dengan benar sejak hari pertama, dan lewati fase tumpukan anotasi sepenuhnya.