Mengapa AISpeech Memilih Apache APISIX Alih-alih NGINX sebagai k8s Ingress Controller

Kata Pengantar

Halo semuanya, saya Jin Wei dari AISpeech, sebuah perusahaan teknologi tinggi yang khusus dalam pengenalan dan analisis suara komputer, dan saya di sini untuk membahas integrasi Apache APISIX dengan K8s sebagai pengganti ingress native.

Pada saat penulisan ini, Apache APISIX telah diterapkan di lingkungan produksi kami dan mengambil alih sebagian lalu lintas masuk bisnis. Kami secara bertahap memigrasikan lalu lintas ingress native, seperti yang ditunjukkan pada gambar di bawah ini.

Sebenarnya, APISIX-ingress-controller mendaftarkan ip pod ke node upstream, sehingga lalu lintas bisnis dapat mengakses pod secara langsung dan melewati kube DNS. Anda dapat mengimplementasikan beberapa kebijakan load balancing tertentu melalui plugin berdasarkan hal ini. Oleh karena itu, di satu sisi, kami mengandalkan kemampuan routing dinamis Apache APISIX untuk distribusi lalu lintas. Di sisi lain, kami menambahkan beberapa plugin kustom untuk memenuhi kebutuhan bisnis.

Dari diagram di atas, APISIX-ingress-controller terlihat berulang dengan ingress native. Dalam artikel ini, kami akan menjelaskan secara singkat mengapa kami meninggalkan ingress native dan membangun ingress controller kami sendiri berdasarkan Apache APISIX.

Apa Itu Ingress

Secara singkat, Ingress adalah cara Kubernetes untuk menangani lalu lintas eksternal.

Masalah yang Dipecahkan oleh Ingress

Karena layanan dalam kluster Kubernetes adalah jaringan virtual, lalu lintas eksternal memerlukan setidaknya ip publik dan port yang dipetakan dengan benar untuk mengakses layanan internal di dalam kluster.

Kubernetes memiliki berbagai cara (NodePort, LoadBalancer, Ingress, …) untuk mengekspos antarmuka untuk mengakses layanan internal Kubernetes. Sebagai perbandingan, Ingress jelas merupakan cara yang lebih ekonomis untuk mencapai reverse proxy dengan mengekspos sejumlah kecil IP publik.

Berbicara tentang reverse proxy, kita juga bisa membangun NGINX langsung untuk melakukannya, tetapi jauh lebih sulit untuk mempertahankan sinkronisasi status layanan yang mudah berubah di Kubernetes di NGINX.

Kabar baiknya adalah Kubernetes secara resmi menyediakan dan memelihara ingress controller NGINX untuk membantu menyelesaikan reverse proxy. Dengan ingress controller NGINX ini, kita dapat memproksi semua lalu lintas yang ingin mengakses Kubernetes dan mengarahkannya ke layanan backend dengan benar.

Masalah dengan Kubernetes Native Ingress Controller

Ingress controller NGINX membantu kita mempertahankan sinkronisasi status antara kluster Kubernetes dan NGINX, dan menyediakan kemampuan reverse proxy dasar, jadi mengapa kita membangun ingress sendiri? Kami mengharapkan lebih dari ingress controller untuk memenuhi lebih banyak kebutuhan bisnis.

Setelah menggunakan ingress controller native Kubernetes, kami menemukan masalah berikut yang menonjol:

1. Masalah Reloading

   Ingress native Kubernetes dirancang untuk meneruskan file konfigurasi YAML ke ingress controller, mengubahnya menjadi file konfigurasi NGINX, dan kemudian memicu reloading untuk membuat konfigurasi berlaku.

   Ini tidak dapat diterima, terutama ketika lalu lintas menggunakan koneksi panjang, yang dapat menyebabkan kecelakaan.

   Sebaliknya, Apache APISIX mendukung hot reloading konfigurasi, sehingga Anda dapat mendefinisikan dan memodifikasi rute kapan saja tanpa memicu reload NGINX.

2. Menulis skrip dan mengisi parameter dalam anotasi

   Ingress controller native mendukung cuplikan skrip yang didefinisikan oleh anotasi dalam file YAML, yang terasa seperti solusi sementara untuk mendukung fitur canggih dan, jujur, sangat sulit dikelola. Banyaknya skrip anotasi menyebabkan masalah bagi staf DevOps.

   Di Apache APISIX, kita dapat menulis logika melalui kode plugin untuk mengekspos antarmuka konfigurasi sederhana yang memudahkan pemeliharaan konfigurasi dan menghindari gangguan skrip pada staf DevOps.

3. Kurangnya dukungan untuk load balancing stateful

   Kebijakan load balancing canggih tidak didukung, seperti “session persistent”, dll. Kubernetes adalah sistem manajemen aplikasi kontainer yang berorientasi pada operasi, yang mungkin terkait dengan fakta bahwa Kubernetes mempromosikan pendekatan deployment stateless, sehingga Kubernetes tidak akan secara resmi mendukung kebijakan load balancing yang kontradiktif ini dalam waktu dekat. Sebenarnya, Google telah mencoba mengatasi masalah ini dengan solusi service mesh-nya (Istio). Arsitektur Istio sempurna, tetapi dengan mengorbankan kinerja, yang mungkin diselesaikan dengan mixer v2.

   Karena Kubernetes mendukung penskalaan, kita juga dapat memperluas Apache APISIX untuk memenuhi kebutuhan load balancing canggih kami, karena Apache APISIX tidak hanya mendukung “session persistent” dan load balancing lainnya secara native, tetapi juga memiliki kemampuan untuk memperluas fase balancer.

4. Bobot dinamis

   Layanan bisnis sering perlu mengontrol lalu lintas berdasarkan persentase, yang menjadi masalah di Kubernetes.

   Meskipun Kubernetes mendukung IPVS (IP Virtual Server) setelah versi 1.8, baik parameter awal “kube-proxy” maupun anotasi “kube-route” tidak semudah Apache APISIX, yang secara internal mengabstraksikan rute, layanan, konsumen, upstream, plugin, dan objek utama lainnya. Menyesuaikan bobot operasi semacam itu secara alami didukung, cukup dengan memodifikasi “node weight” di bawah “upstream”.

5. Kemampuan ekstensi yang tidak fleksibel

   Meskipun Ingress awalnya dirancang untuk menangani lalu lintas eksternal, tidak ada permintaan yang lebih sedikit untuk lalu lintas eksternal daripada untuk lalu lintas internal.

   Rilis canary tingkat layanan, pemutusan sirkuit, kontrol aliran, autentikasi, kontrol lalu lintas, dan persyaratan lainnya lebih sering diimplementasikan pada Ingress.

   Apache APISIX menyediakan dukungan plugin untuk skalabilitas, dan selain plugin resmi, Anda dapat menyesuaikan plugin untuk memenuhi karakteristik Anda sendiri.

   Ada juga beberapa masalah konfigurasi yang disebabkan oleh ConfigMap dan Namespaces, yang terkait dengan cara kami menggunakannya dan tidak bersifat umum, jadi saya tidak akan membahasnya di sini.

Apache APISIX Ingress Controller

Karena kemampuan routing dan skalabilitas Apache APISIX yang kuat, menggunakan Apache APISIX sebagai implementasi Ingress dapat dengan mudah menyelesaikan masalah yang disebutkan di atas dan memberikan opsi ingress controller tambahan kepada komunitas. Diagram waktu adalah sebagai berikut:

Untuk mengimplementasikan ingress controller Apache APISIX, kita perlu menyelesaikan dua jenis masalah mendasar: satu adalah menyelesaikan sinkronisasi antara kluster Kubernetes dan status Apache APISIX; yang lainnya adalah mendefinisikan objek di Apache APISIX di Kubernetes (CRD).

Untuk mengintegrasikan Apache APISIX dengan cepat dan memanfaatkannya, kami membuat proyek Apache APISIX ingress controller (semua orang dipersilakan untuk berpartisipasi), yang saat ini mengimplementasikan jenis masalah dasar pertama: menyinkronkan informasi pod Kubernetes ke upstream Apache APISIX, sambil mengimplementasikan cadangan utama untuk menyelesaikan masalah ketersediaan tinggi-nya sendiri.

Karena Kubernetes menggunakan YAML untuk mendefinisikan status kluster secara deklaratif, kita perlu mendefinisikan CRD (Custom Resource Definitions) untuk objek (rute/layanan/upstream/plugin) di Apache APISIX untuk diintegrasikan ke Kubernetes.

Juga, untuk memudahkan migrasi pengguna ingress Kubernetes yang ada, kami akan mencoba untuk kompatibel dengan item konfigurasi ingress yang ada.

Fitur-fitur ini akan menjadi tujuan upaya kami selanjutnya, dan kami menyambut partisipasi Anda.