Gateway API Kubernetes

 (romaglushko.com)
4 poin oleh GN⁺ 4 jam lalu | 2 komentar | Bagikan ke WhatsApp
  • Pada November 2025, Kubernetes mengumumkan deprecation NGINX Ingress Controller pada Maret 2026, yang saat itu digunakan di lebih dari 40% seluruh cluster; keputusan ini menjadi titik balik yang menegaskan Gateway API sebagai penerus Ingress API
  • Gateway API mencakup cakupan fitur yang jauh lebih luas untuk mengelola traffic inbound, memiliki ekspresivitas yang lebih tinggi daripada Ingress API, dan memperjelas pemisahan concern antar tim
  • Keterbatasan Ingress API meliputi cakupan API yang sempit, ekstensibilitas yang kaku, tidak adanya enforcement kebijakan, batas kepemilikan yang ambigu, serta tidak adanya dukungan cross-namespace yang aman
  • Gateway API menyediakan model resource yang terpisah seperti GatewayClass, Gateway, Listener, dan Route, serta mekanisme keamanan dan ekstensi seperti ReferenceGrant dan Policy attachment
  • CVE berulang pada NGINX Ingress Controller berasal dari cacat struktural, dan dalam jangka panjang migrasi ke Gateway API adalah satu-satunya solusi mendasar

Evolusi Ingress

  • Pada Kubernetes awal tahun 2014, resource Service adalah cara utama untuk mengekspos aplikasi
    • ClusterIP hanya menyediakan nama DNS internal cluster, tanpa akses dari luar
    • NodePort membuka port tertentu di semua node untuk menerima traffic eksternal; jika IP node dipublikasikan maka layanan bisa diakses dari luar
    • LoadBalancer memprovisikan load balancer eksternal dengan IP publik untuk meneruskan traffic
    • ExternalName menyediakan alias dalam cluster untuk layanan eksternal melalui record CNAME
  • Dari keempatnya, hanya NodePort dan LoadBalancer yang bisa langsung digunakan untuk eksposur eksternal
    • NodePort adalah primitif dasar tetapi terlalu low-level; load balancing eksternal antar node dan routing berbasis path harus diimplementasikan sendiri
  • LoadBalancer menambahkan L4 load balancer (TCP/UDP) di atas NodePort dengan provisioning otomatis, yang ditangani oleh Cloud Controller Manager
    • Namun, banyaknya IP publik dan load balancer yang harus dikelola meningkatkan biaya, serta tidak ada titik pusat untuk pengelolaan traffic
  • Alih-alih load balancer terpisah untuk tiap Service, arsitektur yang membuat satu Service LoadBalancer menerima semua traffic lalu meneruskannya ke Deployment reverse proxy seperti NGINX untuk dirutekan berdasarkan path dan hostname menjadi titik awal Ingress API dan Ingress Controller

Ingress Controller

  • Pada 2015, tim Kubernetes memperkenalkan Ingress API sebagai cara untuk mendefinisikan aturan perutean traffic HTTP(S) eksternal ke Service internal

  • Ingress API terdiri dari dua resource, IngressClass dan Ingress, hanya mendefinisikan antarmuka umum dan memerlukan instalasi Ingress Controller untuk perilaku aktual

  • IngressClass

    • Resource cluster-wide yang menentukan controller mana yang akan memproses kumpulan resource Ingress tertentu
    • Memungkinkan operasi paralel beberapa Ingress Controller dalam cluster yang sama; tiap controller hanya memantau resource yang dipilih lewat IngressClass miliknya
    • Controller memerlukan izin ClusterRole untuk membaca dan menggunakan IngressClass

  • Resource Ingress

    • Ingress adalah resource utama dalam Ingress API yang menggabungkan beberapa elemen
      • Mendefinisikan perutean ke Service internal melalui aturan pencocokan berbasis path (exact/prefix) dan host
      • Mendefinisikan konfigurasi TLS untuk traffic inbound
    • Saat resource dibuat, Ingress Controller mendeteksinya, memperbarui konfigurasi internalnya, dan menerapkan aturan routing

  • Masalah pada Ingress API

    • Dalam lingkungan produksi nyata, muncul masalah berikut: cakupan API yang sangat terbatas, ekstensibilitas yang kaku, tidak adanya enforcement kebijakan, batas kepemilikan yang ambigu, dan tidak adanya dukungan cross-namespace yang aman

  • Cakupan API yang sangat terbatas

    • Ingress API bukan sekadar simple, melainkan terlalu minimalis (simplistic), karena hanya menangani hal-hal paling dasar yang diperlukan untuk konfigurasi traffic ingress
    • Fitur berikut yang umum diinginkan pada NGINX tidak didukung secara langsung
      • request timeout, CORS, batas ukuran body maksimum, sesi sticky cookie, pembagian traffic canary, rate limiting, routing berbasis header·query·cookie, modifikasi header
    • Akibatnya, custom annotation menjadi cara standar untuk mengirimkan konfigurasi tambahan, dan beberapa controller seperti Traefik menggunakan CRD mereka sendiri
    • Saat beberapa Ingress Controller digunakan bersamaan, tidak adanya cara konfigurasi terpadu membuat annotation berbeda-beda per controller sehingga portabilitas menurun
    • Ingress hanya menangani routing HTTP(S), sedangkan gRPC (L7)·TCP·UDP (L4) ditangani lewat custom annotation tergantung implementasinya

  • Ekstensibilitas yang kaku

    • custom annotation hanyalah pasangan key-value string, sehingga konfigurasi kompleks harus diserialisasikan ke string dan akibatnya kurang ekspresif

  • Tidak adanya enforcement kebijakan

    • Tim aplikasi dapat menambahkan annotation arbitrer pada resource Ingress; misalnya, mereka bahkan bisa menonaktifkan rate limiting yang diharapkan tim platform berlaku untuk semua route
    • Karena Ingress API sendiri tidak memiliki mekanisme untuk memaksakan perilaku global, ia bergantung pada engine kebijakan eksternal seperti Kyverno atau OPA Gatekeeper

  • Batas kepemilikan yang ambigu

    • Resource Ingress mencampurkan banyak jenis konfigurasi
      • Aturan routing biasanya dimiliki oleh tim aplikasi
      • Konfigurasi hostname dan port dimiliki oleh tim platform yang mengelola DNS, load balancer, dan networking
      • Konfigurasi TLS dimiliki oleh tim platform yang bertanggung jawab atas provisioning sertifikat
      • custom annotation bisa dimiliki oleh salah satu dari kedua tim
    • Dalam sistem kompleks yang dideploy dengan umbrella Helm chart, Ingress biasanya berada di subchart aplikasi, tetapi tim platform juga perlu memperbarui atau memaksakan sebagian konfigurasinya
    • Dari sudut pandang prinsip tanggung jawab tunggal, Ingress memiliki lebih dari satu alasan untuk berubah, sehingga lebih baik dipisahkan menjadi resource yang lebih terfokus
    Iklan

  • Tidak ada dukungan cross-namespace yang aman

    • Resource Ingress tidak dapat mereferensikan Service atau TLS secret di luar namespace-nya sendiri, dan bahkan tidak ada field untuk menentukan namespace pada rules[].backend.service
    • Sebagai jalan memutar, kita bisa membuat Service ExternalName di namespace yang sama untuk menunjuk ke nama DNS dalam cluster dari Service target
    • Namun, pendekatan ini langsung memuat masalah yang termasuk confused deputy attack

Gateway API

  • Gateway API adalah versi generasi berikutnya dari Ingress API yang mengatasi keterbatasan tersebut melalui hal-hal berikut
    • Menangani cakupan fitur yang jauh lebih luas untuk pengelolaan traffic inbound dan meningkatkan ekspresivitas
    • Memperjelas pemisahan concern antar tim dengan mencerminkan pola kepemilikan resource yang umum
    • Mencakup mekanisme ekstensi terdefinisi yang disebut policies serta referensi objek cross-namespace yang fleksibel

GatewayClass

  • Mirip dengan IngressClass, resource ini mendefinisikan kumpulan Gateway yang dimiliki oleh deployment Gateway controller tertentu, dengan makna dan struktur yang pada dasarnya sama seperti IngressClass
  • Dapat mereferensikan custom resource yang berisi konfigurasi Gateway tambahan yang spesifik implementasi
    • Termasuk cara mengekspos Gateway proxy, konfigurasi default bootstrap dan runtime, cara rollout dan scaling deployment, serta opsi lain khusus controller

Gateway

  • Resource Gateway merepresentasikan edge gateway yang diprovisikan secara dinamis, sebuah abstraksi infrastruktur yang menerima traffic inbound dan merutekannya ke service backend yang sesuai

    • Dalam desain Ingress, peran ini dijalankan oleh Ingress Controller, sehingga bisa dianggap sebagai instance Gateway yang diprovisikan secara statis

  • Setiap Gateway mereferensikan GatewayClass untuk menentukan controller mana yang akan memprovisikan dan mengelolanya, dan komponen konfigurasi terpentingnya adalah daftar listener

  • Listener

    • Mendefinisikan cara Gateway menerima traffic masuk; setiap listener adalah titik masuk terpisah yang dijelaskan dengan kombinasi port·protocol·hostname
    • Dapat dikonfigurasi TLS termination; di dunia Ingress informasi ini berada di dalam resource Ingress
    • Unit paling granular tempat Route dapat di-attach ke Gateway

  • ListenerSet

    • listener cocok untuk memusatkan konfigurasi titik masuk, tetapi tidak sesuai bila dibutuhkan ratusan listener
    • Kasus utamanya adalah listener HTTPS dengan pengaturan hostname·TLS per layanan alih-alih satu wildcard TLS certificate; jumlah listener dapat sebanyak jumlah microservice
    • Jika dimodelkan dengan satu Gateway, muncul dua masalah
      • Gateway hanya mendukung maksimal 64 listener
      • Jika banyak tim mengelola listener·TLS, Gateway menjadi bottleneck koordinasi
    • Untuk mendistribusikan dan membuatnya multi-tenant, digunakan resource ListenerSet

  • Listener dan Route yang Diizinkan

    • Setelah konsep Gateway dan Route dipisahkan, muncul masalah baru untuk mengontrol tenant mana yang boleh meng-attach Route ke listener mana
    • listener adalah infrastruktur bersama dengan kegunaan berbeda; misalnya tidak tepat menempelkan HTTPRoute ke listener tls-passthrough-db yang merupakan kanal passthrough ke database, dan juga tidak tepat menempelkan Route dari namespace selain db
    • Karena Route ditambahkan secara self-service, mekanisme allowedRoutes digunakan untuk mencegah salah konfigurasi
    • allowedRoutes membangun hubungan kepercayaan antara Gateway·ListenerSet dan Route dari namespace·tipe route tertentu

Routes

  • listener menerima traffic, tetapi tidak mengetahui bagaimana traffic diproses setelahnya; hal ini ditangani oleh resource Route, inti dari fleksibilitas Gateway API

  • Ada lima resource Route untuk menangani berbagai protokol

    • HTTPRoute: routing traffic HTTP yang diperkuat dan diperluas
    • GRPCRoute: routing yang sadar gRPC
    • TLSRoute: routing berbasis TLS SNI
    • TCPRoute·UDPRoute: meneruskan langsung traffic TCP/UDP pada port listener ke backend
    Iklan

  • Semua resource Route (secara umum disebut xRoutes) memiliki struktur envelope yang serupa

    • parentRefs adalah typed object reference ke resource induk yang menerima Route (umumnya Gateway, ListenerSet, Service di service mesh, dll.); opsi sectionName·port dapat digunakan untuk menunjuk listener tertentu
    • rules mencakup aturan routing·filter·konfigurasi spesifik protokol; setiap rule terdiri dari matches, filters opsional, dan backendRefs opsional; jika filter menangani request sepenuhnya, backendRefs dapat dihilangkan
    • Jika protokol mengizinkan, routing berbasis host pada level Route dimungkinkan melalui field hostnames

  • HTTPRoute

    • Mendefinisikan aturan routing traffic HTTP(S) pada level L7

    • Traffic Matching

      • Mendukung aturan pencocokan berbasis path·host mirip Ingress, serta pencocokan berbasis header·query·method
      • Contoh: canary release khusus klien internal dapat dirutekan ke test deployment dengan pencocokan berbasis header
      • Data plane menerapkan aturan yang paling spesifik, jadi urutan definisi aturan tidak berpengaruh

    • URL Rewrites

      • Dengan filter, sebagian URL request dapat di-rewrite sebelum mencapai backend

    • Header Modifications

      • Menyediakan filter HeaderModifier untuk menambah·menghapus·mengubah header request dan response
      • Menyediakan filter CORS khusus untuk pengaturan Cross-Origin Resource Sharing; secara konsep ini adalah kasus khusus modifikasi header response, tetapi diekspos sebagai tipe filter terpisah

    • Redirects

      • Dapat mengembalikan response redirect ke klien alih-alih meneruskan ke backend; mendukung redirect berbasis path 3xx dan redirect HTTP→HTTPS

    • Traffic Control

      • Traffic dapat dibagi antar layanan backend dengan weight, berguna untuk deployment blue-green dan pengujian A/B
      • traffic mirroring mengirim salinan traffic produksi ke backend tambahan dan dikonfigurasi dengan filter RequestMirror; request asli tetap berjalan ke backend utama
      • mirroring adalah komponen inti tap-and-compare testing untuk membandingkan hasil versi lama dan baru saat refactoring atau migrasi

    • Sticky Sessions

      • Mendukung session persistence, dengan cookie·header dijadikan penanda sesi agar request dari klien yang sama dirutekan secara konsisten ke instance backend yang sama

    • External Authentication

      • Mendukung experimental external authentication filter berbasis gRPC atau HTTP; sebelum meneruskan ke backend, Gateway mengirim header request ke layanan autentikasi eksternal, dan body request hanya dikirim jika diaktifkan secara eksplisit
      • Untuk gRPC, layanan autentikasi eksternal harus mengimplementasikan API protobuf ext_authz milik Envoy
      • Untuk HTTP, jika autentikasi berhasil maka mengembalikan 200; status lain diperlakukan sebagai kegagalan autentikasi

    • Retries & Timeouts

      • Retry dapat diatur untuk route tertentu, dan BackendTrafficPolicy menyediakan retry budget global untuk mencegah retry storm

  • GRPCRoute

    • Karena gRPC berbasis HTTP/2, sebenarnya bisa ditangani dengan HTTPRoute, tetapi ada alasan untuk memodelkannya sebagai resource terpisah
      • Memisahkan opsi yang tidak bermakna untuk gRPC, seperti URL rewrite, agar tiap resource dapat berkembang mandiri sesuai protokolnya
      • Response gRPC dapat mengembalikan HTTP 200, tetapi tetap mengekspresikan error aplikasi melalui header grpc-status·grpc-message, yang penting untuk retry dan metrik yang benar
      • Pengalaman pengguna meningkat bila aturan didefinisikan dengan istilah gRPC tingkat tinggi
    • path matcher pada HTTPRoute digantikan oleh method matcher; secara internal tetap mencocokkan path, tetapi diekspos dalam bentuk service·method
    • Dapat menangani header request·response, tetapi tidak mendekode payload gRPC sehingga tidak bisa melakukan routing berdasarkan field protobuf tertentu
    • Mendukung sebagian filter HTTPRoute seperti traffic mirroring·weighted load balancing dan modifikasi header

  • TCPRoute dan UDPRoute

    • Hanya meneruskan traffic yang mencapai port listener ke layanan backend; saat ini tidak mendukung matcher maupun filter
    • Kedua tipe mendukung weighted load balancing di antara banyak backend

  • TLSRoute

    • Merutekan traffic terenkripsi TLS ke backend berdasarkan SNI yang diberikan saat TLS handshake
    • Umumnya digunakan untuk TLS passthrough; Gateway memeriksa SNI untuk memilih backend lalu meneruskan koneksi terenkripsi tanpa melakukan TLS termination, sementara backend menangani terminasi TLS
    • Beberapa implementasi seperti Envoy Gateway atau kgateway juga mendukung TLS termination di edge, tetapi ini adalah fitur ekstensi
    • Route harus menyatakan hostname, yang harus cocok dengan nilai SNI dan beririsan dengan hostname listener Gateway; matcher dan filter tidak didukung, tetapi weighted load balancing didukung

  • Route Filter Extensions

    • HTTPRoute dan GRPCRoute menyertakan mekanisme perluasan untuk custom filter serta pemrosesan request/response melalui filter extensionRef, yang menunjuk resource lain dengan typed object reference
    • Contoh: Envoy Gateway menyediakan CRD HTTPRouteFilter yang mengembalikan response secara langsung tanpa layanan backend

  • Target Backend

    • Secara default mendukung Service standar (paling umum) dan ServiceImport untuk multi-cluster sebagai target backend
    • Karena ditentukan dengan typed object reference, dapat diperluas ke custom resource per implementasi
    • Contoh: Envoy Gateway mendukung resource custom Backend yang menunjuk ke upstream eksternal seperti FQDN, IP, dan soket UNIX
    Iklan

  • ReferenceGrant

    • Gateway API memperlakukan referensi lintas namespace sebagai konsep kelas satu dalam desain standarnya, tetapi ada risiko keamanan
    • Contoh confused deputy attack: jika penyerang menguasai satu namespace, akses ke layanan yang dilindungi bisa bocor lewat izin membuat Ingress, Service, dan EndpointSlice
      • Ingress baru mengarah ke Service baru di namespace yang sudah dikompromikan
      • Service tersebut tidak memiliki selector sehingga tidak cocok dengan deployment mana pun dan memungkinkan penyediaan EndpointSlice secara manual
      • Penyerang memalsukan EndpointSlice agar menyertakan IP pod backend yang dilindungi di namespace lain, lalu membuat jalur masuk kedua ke API yang dilindungi dengan penyelarasan port
      • Hasil yang sama juga bisa dicapai dengan ExternalName Service
    • Untuk memitigasi hal ini, diperkenalkan resource ReferenceGrant, yaitu mekanisme kepercayaan dua arah yang mendefinisikan namespace mana yang diizinkan untuk mereferensikan resource miliknya oleh suatu namespace
    • Gateway Controller mempertimbangkan ReferenceGrant saat ada referensi lintas namespace ke target backend atau TLS secret, sehingga confused deputy attack menjadi lebih sulit
    • Namun, ReferenceGrant hanya menjamin legitimasi referensi dan tidak terlibat dalam perilaku setelah trafik diteruskan; perlindungan ini dapat dilengkapi dengan NetworkPolicies untuk memblokir akses ke port API yang dilindungi

Policies

  • Policy attachment adalah pola ekstensi yang kuat untuk menerapkan perilaku dan efek secara hierarkis ke satu atau lebih komponen Gateway API tanpa mengubah resource asal
  • Autentikasi adalah contoh yang representatif
    • Jika autentikasi diterapkan ke seluruh Gateway (atau ListenerSet), maka semua Route yang terpasang saat ini maupun di masa depan akan terdampak secara hierarkis, sambil tetap memungkinkan pengecualian di tingkat Route seperti route publik
    • Autentikasi dapat dikendalikan oleh tim yang tidak terkait dengan Gateway maupun Route, sehingga dirancang agar mereka tidak perlu mengubah resource tersebut secara langsung
    • Meski ada standar seperti OAuth 2 dan OIDC, konfigurasi autentikasi sangat bergantung pada implementasi sehingga sulit membuat abstraksi yang berlaku untuk semua implementasi
  • Contoh: resource SecurityPolicy milik Envoy Gateway dapat mengatur verifikasi token JWT; Policy adalah pendekatan modern dan lebih ekspresif yang menggantikan konfigurasi berbasis annotation pada era Ingress
  • Hanya ada dua Policy bawaan
    • BackendTLSPolicy: menginstruksikan Gateway agar terhubung ke backend upstream melalui TLS
    • BackendTrafficPolicy: menetapkan retry budget untuk backend tertentu; jika melebihi kuota retry global, akan mengembalikan 503, bertindak seperti circuit breaker untuk mencegah retry storm

Ownership

  • Resource Gateway API di dalam cluster biasanya dimiliki oleh dua tim
    • Platform team mendefinisikan GatewayClass, Gateway, ListenerSet, serta konfigurasi LoadBalancer dan TLS, dan dapat mengelola Policy global yang berlaku untuk sebagian atau seluruh Gateway
    • Application/Service team terutama berfokus pada resource Route miliknya, dan bila perlu menerapkan Policy di tingkat Route
  • Karena fleksibilitasnya tinggi, berbagai model kepemilikan dapat dibangun, misalnya platform team memiliki Route yang dikumpulkan dalam satu namespace

Typical Architecture

  • Gateway API tidak banyak berasumsi tentang arsitektur implementasi, tetapi pendekatan yang umum adalah pemisahan control plane dan data plane
  • Gateway Controller berperan sebagai operator Kubernetes untuk control plane, memantau resource Gateway API dan CRD untuk menyusun konfigurasi data plane yang diinginkan, dan membutuhkan hak istimewa tambahan untuk membaca serta mengubah resource
  • Data plane Gateway adalah proxy yang menangani trafik sesuai konfigurasi; yang umum digunakan antara lain Envoy Proxy, NGINX, dan Traefik, dengan provisioning proxy per Gateway atau berbagi tergantung implementasi
  • Pemisahan control/data plane adalah pilihan desain yang menguntungkan untuk menghindari cacat keamanan mendasar yang ditemukan pada NGINX Ingress Controller

Migrasi Ingress

  • Ada empat opsi untuk menangani deprecation NGINX Ingress Controller, ditinjau dari yang paling tidak invasif

  • Do Nothing

    • Bukan pilihan terbaik, tetapi dalam beberapa kasus masih mungkin; di homelab motivasinya bisa rendah

    • Di enterprise, hal ini sulit diterima karena kerangka regulasi, keamanan, dan kepatuhan mengharapkan perangkat lunak yang tetap dipelihara dan ditambal

      • ISO 27001: mengharapkan manajemen kerentanan, patch, dan pelacakan EOL
      • SOC 2 Type II: mengharapkan pemindaian kerentanan, manajemen patch, dan SLA remediasi
      • HIPAA Security Rule: mewajibkan perangkat lunak lawas dan tidak ditambal dimasukkan dalam analisis risiko
      • PCI DSS v4.0.1: mensyaratkan identifikasi komponen yang tidak didukung dan rencana remediasi, serta menetapkan tenggat penanganan kerentanan serius
      • FedRAMP: mengharapkan perangkat lunak yang tidak didukung diganti dengan alternatif yang dipelihara, dengan tenggat remediasi berdasarkan tingkat keparahan

    • Dalam sebagian besar framework, perangkat lunak EOL menjadi masalah nyata saat kerentanan baru diungkap

    • Analisis CVE

      • Status CVE NGINX Ingress Controller dalam 5 tahun terakhir
        • Total 20 kerentanan
        • Tahun 2021 ada 4 High terkait kebocoran secret
        • Tahun 2022 ada 1 High terkait kebocoran credential controller
        • Tahun 2023~2024 ada 3 High
        • Tahun 2025 ada 6, termasuk 1 Critical (IngressNightmare) dan 4 High terkait injeksi konfigurasi NGINX
        • Tahun 2026 ada 6, termasuk 3 High terkait injeksi konfigurasi NGINX
      • CVE 2021~2022 terutama berasal dari konfigurasi NGINX yang diberikan pengguna tanpa sanitasi di dalam annotation, yang memicu injeksi konfigurasi, kebocoran informasi, dan kebocoran secret; Kubernetes kemudian menambahkan validasi
      • CVE 2023~2024 terutama merupakan bypass terhadap validasi annotation tersebut
      • IngressNightmare(CVE-2025-1974) memperburuk keadaan; sebelumnya dibutuhkan izin untuk membuat atau mengubah resource Ingress, tetapi dengan akses jaringan saja ke admission controller, eksekusi kode jarak jauh dimungkinkan dalam konteks controller ingress-nginx melalui bug mirip injeksi konfigurasi, dan setelah itu Secret yang bisa diakses controller dapat bocor
      • Gelombang tahun 2026 juga melanjutkan pola injeksi konfigurasi melalui annotation, path, dan comment
      • Kerentanan-kerentanan ini berulang kali menargetkan kelemahan desain yang sama
        • Controller sangat fleksibel dan mengekspos cakupan fitur NGINX yang luas, sehingga validasi sempurna sulit dilakukan dan injeksi konfigurasi terus berulang
        • Controller menjalankan control plane dan data plane di pod yang sama serta berbagi filesystem, sehingga dampak insiden meluas
        • Controller sering memiliki akses ke Secret di seluruh cluster, sehingga injeksi konfigurasi yang berhasil dapat berujung pada kebocoran secret skala cluster
      • Karena masalahnya bersifat struktural, CVE tambahan kemungkinan akan terus muncul; bertahan di controller asli tanpa rencana migrasi adalah pilihan yang berisiko
      Iklan

  • Menggunakan Fork NGINX Controller

    • Jalur paling sederhana adalah beralih ke fork yang masih dipelihara
      • Fork Chainguard tampaknya tidak menyediakan image hasil build, dan ini kemungkinan merupakan bagian dari produk berbayarnya
    • Dapat mengurangi risiko terpapar CVE baru dan mempertahankan sistem tanpa perubahan besar, tetapi hanya solusi jangka pendek
    • Chainguard tidak bermaksud terus mengembangkan controller ini sebagai proyek jangka panjang, melainkan memberikan perbaikan CVE secara best-effort agar pengguna punya waktu untuk bermigrasi

  • Menggunakan Ingress Controller lain

    • Resource Ingress sendiri tidak deprecated, jadi beralih ke Ingress Controller lain yang masih dipertahankan juga valid, contohnya HAProxy·Istio·Traefik
    • Perlu migrasi annotation di seluruh sistem, dan tingkat kesulitannya berbeda tergantung seberapa besar ketergantungan pada fitur khusus NGINX
    • Ke depannya lebih banyak proyek akan berpindah ke Gateway API sehingga porsi Ingress akan menurun, tetapi untuk sementara Ingress masih tetap sangat layak digunakan

  • Migrasi ke Gateway API

    • Satu-satunya opsi jangka panjang adalah berpindah dari Ingress API ke Gateway API
      • Instal CRD dan implementasi Gateway API
      • Konfigurasikan GatewayClass·Gateway·dan bila perlu resource Policy
      • Migrasikan resource Ingress yang ada ke Route
    • CLI ingress2gateway buatan tim Kubernetes menyediakan konversi otomatis best-effort, tetapi custom annotation tetap perlu diperiksa ulang secara manual setelahnya
    • Timeout, batas unggah file, batas ukuran body, dan sebagainya harus dimigrasikan dengan akurat; jika ada yang terlewat atau salah dipetakan, asumsi aplikasi bisa rusak secara diam-diam
    • Peralihan trafik dari LoadBalancer milik Ingress Controller ke LoadBalancer milik Gateway proxy baru perlu direncanakan dengan hati-hati, dan tidak harus dilakukan secara big-bang
      • Ingress Controller bisa dipertahankan sementara sebagai titik masuk publik, lalu hanya sebagian trafik dikirim ke data plane Gateway API untuk uji trafik nyata sebelum dialihkan secara bertahap

Gateway mana yang harus dipilih

  • Setelah memutuskan migrasi, pertanyaan besar pertama adalah implementasi Gateway API mana yang akan digunakan

  • Definisi kasus generic API Gateway dalam artikel ini: gateway yang dapat diskalakan untuk trafik publik North-South yang dideploy di lingkungan yang sepenuhnya Anda kendalikan, dengan pola autentikasi umum dan rate limiting yang fleksibel sebagai fitur bawaan

  • Selain API Gateway, ada juga LLM Gateway dan Agent Gateway, tetapi bagian ini berfokus pada API Gateway klasik

  • Conformance Gateway API

    • Tim Kubernetes menyediakan tes conformance standar untuk memverifikasi akurasi implementasi dalam menangani protokol inti; fokus utamanya pada perilaku fungsional, sementara aspek nonfungsional seperti keandalan, performa, skalabilitas, dan kompleksitas operasional tidak tercakup
    • Sebaiknya memilih implementasi yang conformant, dan jika hasilnya tidak ada di situs resmi, disarankan meminta laporan conformance kepada maintainer

  • Benchmark publik

    • Selain tes resmi, ada benchmark publik yang membahas keandalan dan performa; John Howard, kontributor Istio sekaligus karyawan Solo.io, membuat benchmark untuk implementasi utama, dan Solo.io adalah perusahaan induk kgateway
    • Mencakup test case yang berguna seperti route attachment·propagasi·skala·dan performa pemrosesan trafik umum; karena berbasis pengalaman pribadi, mungkin condong ke kasus tertentu, tetapi tetap bisa dipakai sebagai salah satu sudut pandang evaluasi

  • OSS vs Proprietary

    • Saat ini ada banyak implementasi OSS Gateway API kelas produksi yang kuat, sehingga patut dipertimbangkan serius saat evaluasi; bagi banyak organisasi, OSS adalah titik awal default
    • Fitur seperti OAuth2 dan OIDC, yang dulu membenarkan pembelian produk komersial, kini telah menjadi commodity, dan controller OSS juga menyediakannya sebagai fitur bawaan
    • OSS memungkinkan kualitas dievaluasi langsung sebelum berkomitmen, sedangkan pada produk komersial Anda harus lebih cepat menaruh kepercayaan pada vendor

  • Rekomendasi

    • Dikelompokkan berdasarkan data plane

      • Berbasis Envoy Proxy: Envoy Gateway, Istio, Cilium, kgateway, dll.
      • Berbasis NGINX: NGINX Gateway Fabric, Kong
      • Proxy lainnya: HAProxy Ingress, Traefik

    • Envoy Gateway

      • Controller Gateway API open source berbasis Envoy Proxy yang dikembangkan oleh tim Envoy Proxy; memetakan fitur Envoy ke Gateway API secepat mungkin secara langsung, sehingga abstraksi yang spesifik produk lebih sedikit daripada Istio dan lebih mudah dipahami
      • Tidak mendukung Ingress API, dan dapat diperluas dengan Envoy AI Gateway untuk fungsi LLM·MCP gateway·dan Inference Pools
      • Ringan serta sederhana untuk dideploy dan dioperasikan, dengan fokus pada API Gateway (North-South), dan mendukung fitur
        • pola keamanan seperti external authentication·validasi JWT·authorization berbasis JWT claim·OIDC·IP allowlisting·autentikasi static API key·credential injection, dll.
        • global rate limit policy yang fleksibel dengan pengaturan tingkat global maupun route, shadow mode, pengaturan request cost, dll.
        • pembatasan connection·bandwidth·ukuran file, routing sadar availability zone, multi-cluster dasar berbasis ServiceImport, kompresi respons Brotli·gzip·zstd, direct response·dan response override
        Iklan
      • Skalabilitasnya juga tinggi: dapat menulis layanan gRPC untuk memodifikasi request·response·dan konfigurasi xDS, serta menulis plugin dengan Lua atau bahasa yang bisa dikompilasi ke WASM (Go·Rust)
      • Menyertakan resource Backend kustom untuk resource eksternal FQDN·IP dan yang menunjuk ke UNIX socket untuk sidecar
      • Saat ini terdaftar sebagai partially conformant karena beberapa tes yang dilewati, tetapi secara fungsional hampir memenuhi semua item, serta terintegrasi dengan proyek CNCF seperti KEDA dan KNative
      • Jika Anda hanya membutuhkan API Gateway yang kaya fitur, ini adalah pilihan yang baik

    • Istio

      • Service mesh berbasis Envoy Proxy sekaligus proyek CNCF Graduated, terdaftar sebagai conformant dalam tes Gateway API
      • Paket yang mencakup Ingress Controller·controller Gateway API·dan service mesh, serta dapat menyediakan fungsi gateway LLM·MCP·dan A2A melalui integrasi agentgateway
      • Mendukung multi-cluster tingkat lanjut dengan Admiral dan lainnya, memiliki profil deployment yang luas, komunitas besar, banyak materi seperti buku O'Reilly, dan berguna untuk lingkungan pemerintah serta FedRAMP berkat enkripsi pod-to-pod berbasis mTLS
      • Kekurangannya, mode sidecar boros sumber daya dan memiliki banyak konsep internal sehingga kurva pembelajarannya curam
      • Menawarkan setup ringan melalui ambient mode, tetapi untuk kasus L7 tingkat lanjut mungkin tidak sefitur sidecar; jika membutuhkan kebijakan yang lebih kuat dan kontrol L7, pertimbangkan menggabungkan Envoy Gateway sebagai ingress gateway·dan waypoint proxy
      • Paling tepat ketika service mesh adalah prioritas utama dan Gateway API bersifat sekunder; jika hanya membutuhkan API gateway, ini mungkin terasa agak kurang pas

    • kgateway

      • Gateway open source CNCF Sandbox berbasis proyek Gloo, mendukung Envoy Proxy dan agentgateway (fitur AI gateway) sebagai data plane, serta dapat memakai instance data plane milik sendiri yang dikelola secara eksternal
      • Memiliki conformance Gateway API sempurna dan nyaris menjadi satu-satunya yang memenuhi semua item
      • Pada data plane Envoy, mendukung validasi JWT·OAuth2/OIDC·external authentication·kontrol akses IP, Envoy global rate limiting, serta mengekspos pemrosesan request·response berbasis ext_proc, tetapi tampaknya tidak mengekspos plugin Lua·WASM atau modifikasi langsung raw xDS
      • Dengan mesin transformasi kuat berbasis template MiniJinja, transformasi header·response body·dan status dapat didefinisikan secara deklaratif dalam resource TrafficPolicy
      • Dapat diintegrasikan dengan Istio dan edge proxy, tetapi bukan service mesh sendiri; mendukung Route hierarkis di mana satu Route mendelegasikan penanganan trafik ke Route lain, dan memiliki CRD AwsLambda kustom untuk memanggil AWS Lambda secara langsung
      • Meski vendor mengklaim deployment yang luas, umpan balik independen masih belum banyak, sehingga dari sudut pandang komunitas publik proyek ini tampak masih dalam tahap berkembang

  • Traefik

    • Reverse proxy open source populer yang ditulis dengan Go, mendukung Ingress API dan Gateway API, populer terutama di komunitas homelab berkat dokumentasi yang bagus, codebase yang rapi, konfigurasi sederhana, dan deployment yang mudah

    • Mendukung fitur inti Gateway API dan beberapa fitur tambahan, tetapi ListenerSet dan traffic mirroring melalui Gateway API masih belum didukung (mirroring dimungkinkan dengan backend TraefikService kustom)

    • Model ekstensinya berbasis middleware, menghubungkan Route ke Middleware CRD dengan filter ExtensionRef, dan middleware bawaan menyediakan ForwardAuth (delegasi autentikasi eksternal, mirip Envoy ext_authz), IP allowlisting dan CORS, pembatasan koneksi, retry, circuit breaker, kompresi, custom error page, dan lain-lain

    • Melalui middleware Plugin, plugin YAEGI dan WASM kustom dapat dihubungkan (terutama untuk memodifikasi request dan response), tetapi verifikasi JWT, OIDC, dan OAuth2 Client Credentials hanya tersedia sebagai plugin berbayar

    • Menyediakan distributed rate limiting dasar melalui Middleware CRD (bucket IP, host, header), tetapi konfigurasinya kurang fleksibel dan karena dipasang melalui ExtensionRef, bukan policy attachment, hierarki seperti penerapan global lalu override di tingkat route sulit dilakukan

    • Tidak ada pemisahan control plane/data plane yang jelas sehingga arsitekturnya lebih dekat ke NGINX Ingress; pod yang sama memantau resource dan memproses traffic, satu deployment mengelola semua Gateway di namespace yang diawasi tanpa memprovisikan proxy secara dinamis per Gateway, sehingga titik kegagalan tunggal dan isolasi yang lebih lemah dapat menimbulkan masalah ketahanan pada skala besar

    • Saat memilihnya, disarankan melakukan load test dengan perkiraan traffic yang akan dihadapi; terutama karena ada keluhan yang pernah terdengar tentang performa Traefik, jadi perlu lebih berhati-hati

    • NGINX Gateway Fabric

      • Implementasi Gateway API resmi dari F5 berbasis NGINX (NGF), memiliki conformance yang kuat, dan pada versi terbaru menambahkan dukungan untuk Gateway API 1.5 serta CORS dan modifikasi header request/response melalui filter HTTPRoute standar
      • Beberapa fitur seperti autentikasi JWT dan OIDC, session persistence berbasis cookie, serta pembaruan upstream tanpa reload NGINX masih bergantung pada NGINX Plus, padahal ini adalah kebutuhan API Gateway yang umum
      • Dengan SnippetsPolicy dan SnippetsFilter kustom, konfigurasi NGINX kustom dapat disisipkan pada berbagai tingkat config yang dihasilkan, sehingga memudahkan migrasi tanpa harus menulis ulang konfigurasi kustom yang sangat banyak dari NGINX Ingress lama
      • Mendukung rate limiting melalui RateLimitPolicy kustom, tetapi ini adalah local rate limiting sehingga status berada di data plane NGINX; saat menjalankan banyak replika NGF, batas efektif berubah sesuai jumlah instance, sehingga sulit menerapkan pembatasan ketat per pengguna
      • Sebagai escape hatch ekstensi milik NGINX sendiri, tersedia scripting JavaScript ringan dan Lua, auth_request untuk delegasi autentikasi eksternal (mirip Envoy ext_authz dan Traefik ForwardAuth), serta modul C kustom; tetapi modifikasi request/response berbasis layanan eksternal dengan metode ext_proc tidak didukung
      • Di NGF 2.0, arsitekturnya dirombak untuk memisahkan control plane/data plane dan mendukung banyak resource Gateway; sebelumnya arsitekturnya merupakan kekhawatiran besar

    • Cilium Service Mesh

      • Banyak cluster menggunakan Cilium sebagai CNI, dan service mesh sidecar-less berbasis eBPF ini mencakup implementasi Gateway API berbasis Envoy Proxy, sehingga jumlah komponen bisa dikurangi dan tech stack bisa dibuat lebih ramping
      • Namun fokus utamanya adalah conformance Gateway API, dan fitur Envoy berguna di luar Gateway API tidak diekspos sebagai konfigurasi kelas satu; misalnya tidak ada dukungan kelas satu untuk ekstensi dan plugin Envoy, IP allowlisting, verifikasi JWT, authorization berbasis claim, maupun OIDC
      • Kecuali benar-benar yakin bahwa fitur Gateway API Cilium saat ini sudah cukup, ini tidak direkomendasikan sebagai API Gateway umum dibanding opsi yang lebih kaya seperti Envoy Gateway, kgateway, atau Istio

    • Kong

      • API Gateway populer berbasis NGINX, dan Kong Operator mendukung Ingress maupun Gateway API
      • Kekhawatiran utamanya adalah strategi OSS; tampaknya penerbitan image Docker prebuilt untuk versi Gateway open source baru telah dihentikan, dan image OSS mungkin berhenti di sekitar lini rilis 3.10 sehingga Anda mungkin perlu membangun, menambal, memperkuat, dan memeliharanya sendiri
      • Ada spekulasi publik bahwa langkah ini terkait upaya mengurangi perpindahan pelanggan enterprise, meski ini tidak bisa dianggap fakta pasti; bagaimanapun arah OSS terasa kurang dapat diprediksi
      • Karena itu, ini tidak direkomendasikan kecuali Anda berniat membeli lisensi enterprise atau siap menanggung sendiri packaging dan pemeliharaan OSS

Summary

  • Menelusuri evolusi pola ingress Kubernetes dari awal hingga era Gateway API, sekaligus membahas protokol Gateway API itu sendiri secara mendalam
  • GAMMA (memperluas ide Gateway API ke service mesh) dan Inference Extension (mendefinisikan dan mengoptimalkan workload inferensi Kubernetes) sengaja dikecualikan dari cakupan karena merupakan topik yang memerlukan pembahasan mendalam tersendiri
  • Juga meninjau implementasi Gateway API yang tersedia beserta kriteria pemilihannya

Bacaan terkait

2 komentar

 
click 1 jam lalu

Tahun lalu saya sempat ingin mencoba NGF, tetapi saat itu tidak ada cara untuk membuat autentikasi berbasis header Authorization, jadi akhirnya saya memilih Envoy.
Saya lebih suka nginx daripada Envoy, jadi kalau nanti dukungan penuh untuk Gateway API sudah tersedia, sepertinya berikutnya saya akan mencoba NGF.
 
hmmhmmhm 2 jam lalu

Sepertinya Envoy akan makin naik daun.