Kubernetes Gateway API v1.0: Haruskah Anda Beralih?
December 15, 2023
Sudah lebih dari sebulan sejak Kubernetes Gateway API merilis versi 1.0, menandakan lulusnya beberapa API kunci ke status umum yang tersedia.
Saya menulis tentang Gateway API ketika API tersebut lulus ke status beta tahun lalu, tetapi setahun kemudian, pertanyaan yang sama masih muncul. Haruskah Anda beralih dari Ingress API ke Gateway API?
Jawaban saya dari tahun lalu adalah Anda sebaiknya tidak melakukannya. Dan saya memiliki alasan yang kuat.
Gateway API dan implementasinya masih dalam tahap awal. Di sisi lain, Ingress API sudah stabil dan mencakup beberapa kasus penggunaan utama yang mungkin cocok untuk sebagian besar pengguna.
Untuk pengguna yang membutuhkan lebih banyak kemampuan, saya menyarankan menggunakan sumber daya khusus yang disediakan oleh pengontrol Ingress dengan mengorbankan portabilitas (berpindah antara implementasi Ingress yang berbeda).
Dengan rilis versi 1.0, hal ini mungkin berubah. Gateway API sekarang jauh lebih mampu, dan lebih dari 20 implementasinya dengan cepat mengejar ketertinggalan.
Jadi, jika Anda memulai dari awal dan memilih antara Ingress dan Gateway API, saya sarankan Anda memilih Gateway API jika API dan implementasi yang Anda pilih mendukung semua fitur yang Anda inginkan.
Apa yang Salah dengan Ingress API?
Ingress API bekerja dengan sangat baik, tetapi hanya untuk sebagian kecil kasus penggunaan umum. Untuk memperluas kemampuannya, implementasi Ingress mulai menggunakan anotasi khusus.
Misalnya, jika Anda memilih Nginx Ingress, Anda akan menggunakan beberapa dari puluhan anotasi yang tidak portabel jika Anda memutuskan untuk beralih ke implementasi Ingress lain seperti Apache APISIX.
Anotasi khusus implementasi ini juga sulit dikelola dan mengalahkan tujuan mengelola Ingress dengan cara yang sesuai dengan Kubernetes.
Pada akhirnya, implementasi pengontrol Ingress mulai mengembangkan CRD mereka sendiri untuk mengekspos lebih banyak fitur kepada pengguna Kubernetes. CRD ini spesifik untuk pengontrol Ingress. Tetapi jika Anda dapat mengorbankan portabilitas dan tetap menggunakan satu pengontrol Ingress, CRD lebih mudah digunakan dan menawarkan lebih banyak fitur.
Gateway API bertujuan untuk menyelesaikan masalah ini sekali dan untuk selamanya dengan menyediakan ketidakbergantungan vendor dari Ingress API dan fleksibilitas dari CRD. API ini diposisikan dengan sangat baik untuk mencapai tujuan ini.
Dalam jangka panjang, Ingress API tidak diharapkan untuk menerima fitur baru apa pun, dan semua upaya akan dilakukan untuk menyatu dengan Gateway API. Jadi, mengadopsi Ingress API dapat menyebabkan masalah ketika Anda secara tidak sengaja mencapai batas kemampuannya.
Manfaat yang Jelas
Ekspresif, dapat diperluas, dan berorientasi peran adalah ide kunci yang membentuk pengembangan Gateway API.
Tidak seperti Ingress API, Gateway API adalah kumpulan dari beberapa API (HTTPRoute, Gateway, GatewayClass, dll.), masing-masing melayani peran organisasi yang berbeda.
Misalnya, pengembang aplikasi hanya perlu memperhatikan sumber daya HTTPRoute, di mana mereka dapat mendefinisikan aturan untuk mengarahkan lalu lintas. Mereka dapat mendelegasikan detail tingkat kluster kepada operator yang mengelola kluster dan memastikan bahwa kluster tersebut memenuhi kebutuhan pengembang menggunakan sumber daya Gateway.
Desain berorientasi peran dari API ini memungkinkan orang yang berbeda menggunakan kluster sambil tetap mempertahankan kendali.
Gateway API juga jauh lebih mampu daripada Ingress API. Fitur yang memerlukan anotasi di Ingress API didukung secara langsung di Gateway API.
Ekstensi Resmi
Meskipun Gateway API adalah API resmi Kubernetes, API ini diimplementasikan sebagai sekumpulan CRD.
Ini tidak berbeda dengan menggunakan sumber daya Kubernetes default. Tetapi Anda hanya perlu menginstal CRD ini seperti ekstensi resmi.
Ini memungkinkan iterasi yang cepat dibandingkan dengan Kubernetes, yang perlahan bergerak menuju stabilitas jangka panjang.
Apakah Ini Akan Menyebar?
Seperti yang sering diingatkan oleh komik XKCD yang terkenal ini, standar cenderung menyebar.
Versi ini terlihat dalam Ingress dan Gateway API. Biasanya berjalan seperti ini:
- Sebuah standar muncul untuk menyatukan proyek/standar yang berbeda (Kubernetes Ingress API).
- Standar yang disatukan memiliki batasan yang ingin diatasi oleh para implementor (Ingress API terbatas).
- Implementasi menyimpang dari standar karena batasan ini (CRD khusus, anotasi).
- Setiap implementasi sekarang memiliki standarnya sendiri (CRD, anotasi yang tidak portabel).
- Standar baru muncul untuk menyatukan standar yang berbeda ini (Kubernetes Gateway API).
Adalah wajar untuk berpikir bahwa Gateway API mungkin bukan akhir dari segalanya di sini. Tetapi saya percaya API ini memiliki setiap kesempatan untuk menjadi standar untuk routing di Kubernetes.
Sekali lagi, saya memiliki alasan yang kuat.
Adopsi yang luas sangat penting untuk mencegah proliferasi standar karena ada sedikit insentif bagi implementasi untuk bekerja pada standar yang berbeda. Gateway API sudah memiliki lebih dari 25 implementasi.
Sebuah implementasi dapat sesuai dengan Gateway API pada tingkat yang berbeda:
- Inti: Semua implementasi diharapkan sesuai dengan ini.
- Diperluas: Ini mungkin hanya tersedia di beberapa implementasi tetapi merupakan API standar.
- Spesifik Implementasi: Spesifik untuk implementasi tetapi ditambahkan melalui titik ekstensi standar.
Fitur khusus dapat berpindah dari spesifik implementasi ke diperluas ke inti karena lebih banyak implementasi mendukung fitur ini. Artinya, API memungkinkan ruang untuk ekstensi khusus sambil memastikan bahwa API tersebut mengikuti standar.
Proyek Service Mesh Interface (SMI) adalah upaya serupa untuk menstandarisasi konfigurasi service mesh di Kubernetes. Namun, proyek ini tidak mendapatkan banyak perhatian setelah keterlibatan awal proyek service mesh dan perlahan mati.
SMI tidak mendukung banyak fitur umum yang diharapkan pengguna dalam sebuah service mesh. Proyek ini juga tidak bergerak cukup cepat untuk mendukung fitur-fitur ini. Pada akhirnya, implementasi service mesh tertinggal dalam mematuhi SMI (saya pernah bekerja erat dengan SMI di bawah CNCF TAG Network pada proyek yang melaporkan kepatuhan SMI).
Ini adalah alasan universal, tetapi proyek ini sekarang dihidupkan kembali melalui Gateway API. Inisiatif Gateway API untuk Manajemen dan Administrasi Mesh (GAMMA) bertujuan untuk memperluas Gateway API agar bekerja dengan service mesh.
Proyek SMI baru-baru ini bergabung dengan inisiatif GAMMA, yang sangat baik untuk Gateway API. Istio, yang tidak diragukan lagi adalah service mesh paling populer, juga mengumumkan bahwa Gateway API akan menjadi API default untuk mengelola Istio di masa depan. Adopsi seperti ini mencegah proliferasi.
Panduan Migrasi
Dokumentasi Gateway API memiliki panduan komprehensif tentang memigrasikan sumber daya Ingress Anda ke sumber daya Gateway. Alih-alih mengulanginya, mari kita coba menggunakan alat ingress2gateway untuk mengonversi sumber daya Ingress kita ke sumber daya Gateway API yang sesuai.
Anda dapat mengunduh dan menginstal biner untuk sistem operasi Anda langsung dari halaman rilis.
Mari kita ambil sumber daya Ingress sederhana:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: httpbin-route spec: ingressClassName: apisix rules: - host: local.httpbin.org http: paths: - backend: service: name: httpbin port: number: 80 path: / pathType: Prefix
Ini akan mengarahkan semua lalu lintas dengan alamat host yang diberikan ke layanan httpbin.
Untuk mengonversinya ke sumber daya Gateway API, kita dapat menjalankan:
ingress2gateway print --input_file=ingress.yaml
Sumber daya Gateway API ini akan terlihat seperti di bawah ini:
apiVersion: gateway.networking.k8s.io/v1alpha2 kind: HTTPRoute metadata: name: httpbin-route spec: hostnames: - local.httpbin.org rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: httpbin port: 80
Alternatif yang Layak
Ada alternatif lain yang layak untuk mengonfigurasi gateway di Kubernetes.
Di Apache APISIX, Anda dapat menerapkannya dalam mode standalone dan mendefinisikan konfigurasi rute dalam file yaml. Anda dapat memperbarui file yaml ini melalui alur kerja tradisional, dan ini bisa sangat membantu dalam skenario di mana mengelola konfigurasi gateway melalui API Kubernetes tidak diperlukan.
CRD khusus implementasi juga merupakan alternatif yang layak jika Anda tidak berencana untuk beralih ke solusi yang berbeda atau jika konfigurasi Anda cukup kecil untuk dimigrasikan dengan mudah.
Bagaimanapun, Gateway API akan tetap ada.