Mengapa APISIX Ingress Controller Lebih Baik daripada NGINX Ingress Controller?

Ingress mengekspos layanan di Kubernetes, di mana perutean lalu lintas dikontrol oleh aturan yang dikonfigurasi pada sumber daya Ingress. Untuk memenuhi ingress, Anda juga harus memiliki Ingress controller.

Dalam artikel ini, kami akan membandingkan dua Ingress controller populer untuk memberikan wawasan kepada pembaca dalam memilih ingress controller.

• Ingress-NGINX adalah Ingress controller yang diimplementasikan oleh komunitas Kubernetes dan banyak digunakan di komunitas tersebut.
• APISIX Ingress controller menggunakan Apache APISIX, sebuah proyek open-source di bawah ASF (Apache Software Foundation), sebagai data plane-nya.

Ingress NGINX vs. APISIX Ingress

Perbandingan Fitur

Tabel di bawah ini membandingkan fitur dasar Ingress NGINX dan APISIX Ingress, termasuk protokol, pemeriksaan upstream/resiliencies, strategi load balancer, autentikasi, integrasi Kubernetes, dll. Tabel ini diambil dari learnk8s.io.

Perbedaan

Dari gambar di bawah ini, kita dapat melihat bahwa ada lebih banyak fungsi dan fitur bawaan di APISIX Ingress dibandingkan dengan Ingress NGINX, termasuk dukungan protokol, pemeriksaan kesehatan dan pemutus sirkuit, autentikasi, integrasi Kubernetes, dan sebagainya.

Penemuan Layanan

Dalam arsitektur microservices, aplikasi dibagi menjadi banyak layanan mikro. Setiap kali layanan mikro gagal, atau layanan ditingkatkan atau dikurangi, pemanggil perlu diberitahu secepat mungkin untuk menghindari kegagalan panggilan. Oleh karena itu, mekanisme pendaftaran layanan dan penemuan layanan sangat penting dalam arsitektur microservice, biasanya dikelola oleh registri layanan.

Dukungan Protokol

Meskipun kedua ingress mendukung protokol HTTP/HTTPS, APISIX mendukung lebih banyak protokol. Ini mendukung TLS untuk mengenkripsi lalu lintas TCP. Ini juga mendukung MQTT, Dubbo, dan kafka untuk proxying.

Pemeriksaan Upstream/Resiliency

Pemeriksaan Kesehatan

Ketika sebuah node gagal atau bermigrasi, tidak dapat dihindari bahwa node tersebut tidak akan tersedia. Jika sejumlah besar permintaan mengakses node yang tidak tersedia ini, itu akan menyebabkan kehilangan lalu lintas dan gangguan bisnis. Oleh karena itu, perlu melakukan pemeriksaan kesehatan pada node menggunakan probe, dan mengarahkan permintaan ke node yang sehat, sehingga mengurangi kehilangan lalu lintas.

Fungsi pemeriksaan kesehatan belum didukung di Ingress NGINX, tetapi APISIX Ingress menyediakan fungsi ini:

• Pemeriksaan aktif: Gunakan probe untuk memastikan bahwa Pod di backend sehat. Ketika N probe berturut-turut yang dikirim ke node gagal, node akan ditandai sebagai tidak sehat. Load balancer akan mengabaikan node yang tidak sehat sehingga mereka tidak dapat menerima permintaan. Mengaktifkan pemeriksaan kesehatan aktif dapat secara efektif menonaktifkan Pod yang tidak sehat untuk menghindari kehilangan lalu lintas.
• Pemeriksaan pasif: Pemeriksaan kesehatan pasif tidak perlu memulai probe tambahan. Setiap permintaan yang dikirim ke node bertindak sebagai probe. Jika N permintaan berturut-turut ke node yang sehat gagal, node akan ditandai sebagai tidak sehat. Karena tidak dapat merasakan status node sebelumnya, mungkin ada sejumlah permintaan yang gagal. Situasi ini relatif umum selama pembaruan bergulir, dan kita dapat menggunakan degradasi layanan untuk menghindari jumlah permintaan yang gagal.

Contoh APISIX Ingress mengonfigurasi pemeriksaan kesehatan untuk layanan httpbin:

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin
spec:
  healthCheck:
    passive:
      unhealthy:
        httpCodes:
          - 500
        httpFailures: 3
    active:
      type: http
      httpPath: /healthz
      healthy:
        successes: 3
        interval: 2s
        httpCodes:
          - 200

Pemutus Sirkuit

Gateway adalah titik masuk untuk permintaan; itu memulai panggilan ke layanan backend. Ketika lalu lintas memuncak dan beban berat, layanan backend mungkin gagal dipanggil karena timeout atau pengecualian. Ketika kegagalan terjadi, permintaan tidak dapat ditumpuk di gateway. Itu perlu kembali dengan cepat, yang memerlukan pemutusan di gateway.

Mirip dengan fitur pemeriksaan kesehatan, fitur pemutusan layanan tidak didukung di Ingress NGINX. Di APISIX Ingress, plugin api-breaker membantu mengimplementasikan ini.

Contoh konfigurasi pemutus sirkuit di APISIX Ingress:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /status/*
   backends:
   - serviceName: httpbin
     servicePort: 80
   plugins:
   - name: api-breaker
     enable: true
     config:
       break_response_code: 502
       unhealthy:
         http_statuses:
         - 505
         failures: 2
       healthy:
         http_statuses:
         - 200
         successes: 2

Dukungan Lebih Banyak Plugin dan Metode Autentikasi

Ingress NGINX terutama menggunakan Annotations dan ConfigMap untuk konfigurasi, dan plugin yang didukung relatif terbatas. Jika Anda ingin menggunakan JWT, HAMC, atau metode autentikasi lainnya, Anda harus mengintegrasikannya sendiri.

APISIX Ingress mendukung 80+ plugin di APISIX secara native, yang mendukung berbagai metode autentikasi seperti JWT, HAMC, wolf-rbac, dll. Plugin ini menyediakan berbagai fungsi yang mencakup sebagian besar skenario penggunaan.

Contoh autentikasi HMAC di rute APISIX:

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
  name: hmac-value
spec:
  authParameter:
    hmacAuth:
      value:
        access_key: papa
        secret_key: fatpa
        algorithm: "hmac-sha256"
        clock_skew: 0
---

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /ip
   backends:
   - serviceName: httpbin
     servicePort: 80
   authentication:
     enable: true
     type: hmacAuth

Ekstensibilitas Ingress NGINX dan APISIX Ingress

Ketika fitur dasar Ingress controller tidak dapat memenuhi kebutuhan pengguna perusahaan, itu hanya dapat disesuaikan melalui ekstensi. Selanjutnya, kami akan menjelaskan bagaimana Ingress NGINX dan APISIX Ingress memperluas fitur mereka.

Bagaimana Ingress NGINX Memperluas Fiturnya

Ingress NGINX hanya dapat diperluas dengan menyematkan program Lua.

Contoh pengembangan plugin Ingress NGINX:

1. Tulis program Lua contoh-plugin
2. Instal plugin ke /etc/nginx/lua/plugins/<nama plugin Anda> $\rightarrow$ /etc/nginx/lua/plugins/contoh-plugin di pod ingress-nginx
3. Aktifkan contoh-plugin di ConfigMap, dan referensikan objek ConfigMap ini saat menginstal Ingress NGINX

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  plugins: "contoh-plugin"

Bagaimana APISIX Ingress Memperluas Fiturnya

APISIX Ingress menyediakan berbagai metode untuk memperluas fitur, dan pengguna perusahaan dapat memilih metode sesuai kebutuhan mereka. APISIX mendukung:

• Pengembangan plugin melalui Lua: sederhana dan hampir tidak ada kehilangan performa
• Pengembangan melalui plugin-runner: bahasa pemrograman seperti JAVA/Python/Go didukung untuk pengembangan, sehingga pengguna dapat menyesuaikan plugin mereka tanpa mempelajari bahasa baru
• Plugin melalui WASM: bahasa apa pun yang mendukung pembangunan WASM dapat digunakan untuk pengembangan plugin

Selain itu, Anda dapat langsung menulis kode Lua melalui plugin serverless untuk memenuhi kebutuhan bisnis dengan cepat.

Mengapa APISIX Ingress Mendukung CustomResourceDefinition (CRD)?

Saat ini, APISIX Ingress mendukung tiga konfigurasi deklaratif: Ingress, CRD, dan Gateway API. Kami akan membandingkan Ingress dan CRD di sini. Dan kami akan menjelaskan Gateway API setelahnya.

Ingress lebih cocok untuk pengguna perusahaan yang bermigrasi dari Ingress NGINX karena biaya migrasinya rendah. Kekurangannya juga jelas, seperti kemampuan semantik yang lemah, tidak ada spesifikasi standar, dll. Dan ingress hanya dapat diperluas melalui anotasi, tetapi anotasi tidak dapat mendukung skenario kompleks. Sebagai perbandingan, CRD memiliki keunggulan berikut:

• Lebih mudah digunakan karena lebih sesuai dengan semantik desain data plane
• Dapat digunakan kembali untuk mengurangi redundansi
• Peningkatan fungsionalitas dan ekstensibilitas
• Data plane APISIX memiliki komunitas yang aktif, dengan pembaruan dan rilis yang cepat, dan CRD dapat mendukung lebih banyak kemampuan data plane dengan mudah

Masalah Ingress NGINX: Hot Reloading Tidak Didukung

Masalah yang Disebabkan oleh Konfigurasi Statis

Ingress NGINX diimplementasikan terutama berdasarkan file konfigurasi NGINX. Meskipun NGINX dan Lua digunakan untuk mencapai ekstensi fitur, itu hanya sebagian menyelesaikan masalah file konfigurasi statis. Ini menunjukkan kekurangan dalam kemampuan perutean dan reloading. Misalnya, konfigurasi NGINX harus di-reload ketika menambahkan atau memodifikasi aturan. Dengan semakin banyak aturan perutean dan sertifikat, operasi load akan memakan waktu lebih lama, dari beberapa detik hingga lebih dari sepuluh detik. Setiap reload NGINX mengatur ulang status load balancing, berdampak negatif pada lalu lintas online, menyebabkan gangguan singkat, meningkatkan latensi respons, dan mengurangi kualitas load balancing.

Situasi yang Memicu Reload NGINX

• Membuat sumber daya Ingress baru
• Menambahkan bagian TLS ke Ingress yang ada
• Mengubah Anotasi Ingress mungkin juga memengaruhi konfigurasi upstream (misalnya, anotasi load-balance tidak perlu di-reload)
• Menambahkan atau menghapus path di Ingress
• Menghapus sumber daya Ingress, Layanan, atau Rahasia
• Memperbarui Rahasia

Situasi yang tercantum di atas mencakup sebagian besar skenario penggunaan Ingress controller. Dalam lingkungan kluster dengan aplikasi yang sering di-deploy, operasi (pembuatan, pembaruan, penghapusan, dll.) sumber daya seperti Ingress dan Rahasia akan terus dipicu. Ini akan mengakibatkan peningkatan tajam dalam jumlah reload NGINX, berdampak signifikan pada lingkungan produksi.

Arsitektur Ingress NGINX menentukan bahwa itu harus menghasilkan konfigurasi NGINX terlebih dahulu dan melakukan reload untuk menyelesaikan pembaruan konfigurasi. Masalah reloading tidak dapat diselesaikan tanpa menyesuaikan arsitektur. Untuk mengatasi masalah ini, APISIX Ingress tidak lagi bergantung pada konfigurasi NGINX dalam implementasi peruteannya dan beralih ke arsitektur memori murni. Perutean dinamis diwujudkan melalui hot reloading, dan NGINX tidak perlu di-restart.

Gateway API

Keunggulan Kubernetes Gateway API

Kubernetes Gateway API lebih fungsional daripada Ingress dan dirancang untuk mengembangkan jaringan layanan Kubernetes melalui antarmuka yang ekspresif, dapat diperluas, dan berorientasi peran yang diimplementasikan oleh banyak vendor dan dengan dukungan industri yang luas. Gateway API memiliki karakteristik berikut:

• Berorientasi peran: Gateway terdiri dari sumber daya API. Sumber daya API yang berbeda mewakili peran yang berbeda untuk menggunakan dan mengonfigurasi sumber daya jaringan Kubernetes

• Ekspresif yang kuat: Gateway API mendukung fungsionalitas inti, termasuk pencocokan berbasis header, pembobotan lalu lintas, dan kemampuan lain yang hanya mungkin di Ingress melalui anotasi non-standar yang disesuaikan

• Dapat diperluas: Gateway API memungkinkan sumber daya yang berbeda untuk dihubungkan di berbagai lapisan API. Ini memungkinkan kustomisasi granular dalam struktur API

Status Dukungan Gateway API

Kubernetes Gateway API adalah standar untuk memperluas service mesh Kubernetes. Sumber daya Gateway-nya dapat digunakan sebagai API Kubernetes untuk mengelola siklus hidup gateway, yang sangat kuat. Banyak Ingress controller secara aktif mendukungnya, termasuk Istio, Kong, Traefik, dll. Sayangnya, Ingress NGXIN belum berencana untuk mendukung Gateway API (Status Implementasi Gateway API), sedangkan APISIX Ingress sudah mendukung sebagian besar fitur Gateway API: termasuk HTTPRoute, TCPRoute, TLSRoute, UDPRoute, dll.

Ringkasan

Setelah perbandingan menyeluruh antara APISIX Ingress dan Ingress NGINX, kita dapat menyimpulkan bahwa kedua perangkat lunak open-source ini sangat baik dan fungsi dasarnya mirip. Namun, dalam arsitektur microservice, APISIX Ingress menunjukkan lebih banyak keunggulan dalam mendukung tata kelola layanan dan penemuan layanan dengan menyediakan pemeriksaan kesehatan dan pemutusan sirkuit.

Ingress NGINX dicirikan oleh kesederhanaan dan kemudahan penggunaan, dengan beberapa kekurangan yang jelas, seperti kesulitan dalam ekstensi fitur. APISIX Ingress, yang bergabung kemudian, menyelesaikan masalah hot reloading NGINX dan menyediakan ekstensibilitas dan fungsionalitas yang lebih baik. Misalnya, mendukung Gateway API dan CRD memperkaya kemampuan Ingress controller dalam hal pengembangan proyek.

Singkatnya, jika Anda ingin memilih Ingress controller dengan fitur yang lebih kaya dan ekstensibilitas yang lebih baik, APISIX Ingress sangat direkomendasikan. Jika Anda baru mengenal Ingress controller dan tidak memiliki banyak persyaratan fungsional, Ingress NGINX juga merupakan pilihan yang baik karena kesederhanaannya.