Mengapa Jiakaobaodian Memilih APISIX Ingress Controller

Dengan prevalensi Kubernetes (disingkat K8s), kami memiliki lebih banyak opsi selain NGINX Ingress Controller default resmi untuk dipilih, dan Apache APISIX Ingress Controller juga telah menjadi pilihan populer bagi banyak perusahaan. Semakin banyak perusahaan yang secara bertahap mengganti Ingress Controller mereka dengan APISIX Ingress Controller.

Latar Belakang

Wuhan Mucang Technology Co., Ltd didirikan pada tahun 2011, dan produk utamanya adalah puluhan aplikasi mobil seperti Jiakaobaodian. Sejak didirikan lebih dari 10 tahun yang lalu, perusahaan telah mengikuti tren teknologi dan mulai mengadopsi cloud-native pada tahun 2019, dan berbagai proyek di perusahaan telah beralih ke Kubernetes.

Namun pada saat itu, karena K8s baru saja muncul, ada sedikit portal masuk lalu lintas yang dapat dipilih. Oleh karena itu, kami menggunakan Ingress Controller default – NGINX Ingress Controller – selama hampir 4 tahun. Namun, selama periode itu, semakin jelas bahwa NGINX Ingress Controller tidak lagi dapat memenuhi kebutuhan kami, memaksa kami untuk membuat pilihan baru. Setelah membandingkan Ingress Controller yang populer, kami memutuskan untuk menggunakan Apache APISIX sebagai gateway masuk perusahaan.

Masalah dengan NGINX Ingress Controller

Layanan di perusahaan menggunakan protokol HTTP dan TCP, dan hanya insinyur operasi dan pemeliharaan yang tahu persis cara mengkonfigurasi proxy TCP melalui NGINX Ingress Controller. Namun, tenaga operasi dan pemeliharaan terbatas. Akan lebih baik jika kami menyerahkan beberapa operasi dan konfigurasi dasar NGINX kepada tim pengembangan, sehingga dapat menghemat biaya operasi dan pemeliharaan.

Selain itu, kami juga menghadapi masalah berikut:

Beberapa perubahan konfigurasi memerlukan reload;
Proxy TCP memiliki biaya penggunaan yang tinggi, dan tidak dapat mencakup skenario untuk semua jenis lalu lintas;
Routing atau operasi lalu lintas hanya dapat didefinisikan melalui annotations, dan kami tidak dapat mendefinisikan dan menggunakan kembali konfigurasi secara semantik;
Penulisan ulang, pemutusan sirkuit, transfer permintaan, dan operasi lainnya diimplementasikan melalui annotations;
Kurangnya platform manajemen, dan staf operasi dan pemeliharaan perlu beroperasi melalui YAML, yang rentan terhadap kesalahan;
Portabilitas yang buruk;
Tidak mendukung integrasi platform kontainer.

Untuk alasan ini, kami memutuskan untuk mengganti Ingress Controller lama kami dengan yang baru.

Mengapa APISIX Ingress Controller

Kami menyelidiki Apache APISIX dan Ingress Controller lainnya, membandingkannya dalam hal kinerja, kemudahan penggunaan, skalabilitas, dan integrasi platform, dan akhirnya memilih APISIX Ingress Controller sebagai gateway masuk lalu lintas K8s karena alasan berikut.

Skalabilitas yang baik;
Mendukung konfigurasi hot-loading;
Kinerja tinggi;
Banyak plugin;
Mendukung CRD untuk integrasi dengan platform kontainer yang dikembangkan sendiri.

Arsitektur Keseluruhan

Dengan demikian, mari kita lihat seluruh arsitektur gateway. Dalam skenario bisnis aktual, pengguna akan terlebih dahulu meneruskan lalu lintas melalui SLB (Server Load Balancer), dan ketika lalu lintas masuk ke K8s, setiap layanan akan dipanggil melalui kluster APISIX. Kami juga mengimplementasikan banyak fungsi umum (canary release, pengendalian aliran, pemutusan sirkuit API, pengendalian keamanan lalu lintas, pengendalian lalu lintas permintaan/respon, dll.) di sisi gateway untuk menyatukan manajemen layanan, mengurangi kompleksitas bisnis, dan menghemat biaya.

Diagram Arsitektur

Metode Penyebaran

Bisnis kami disebarkan di berbagai platform cloud (Huawei Cloud, Tencent Cloud, Alibaba Cloud), dan kami dapat dengan cepat membawa bisnis kami online melalui Helm Chart, yang didukung oleh APISIX Ingress Controller. Saat menggunakan APISIX Ingress Controller, jika kami menemukan fitur yang dapat ditingkatkan, kami juga akan mengirimkan PR untuk membantu komunitas memperbarui dan mengulangi fitur tersebut. Dalam proses penyebaran aktual, kami menyesuaikan beberapa konfigurasi sesuai dengan karakteristik bisnis kami, seperti:

Membuat NameSpace melalui K8s, menyebarkan APISIX dan APISIX Ingress Controller ke NameSpace yang berbeda, dan memisahkan lalu lintas sesuai dengan lini produk dan kepentingan layanan;
Mengoptimalkan parameter kernel TCP Linux di APISIX initContainer;
Karena kami perlu memisahkan lalu lintas dalam hal lini produk dan kepentingan layanan, informasi ClassName dari K8s perlu dikonfigurasi.

Dengan mengisolasi lalu lintas berdasarkan lini produk dan kepentingan yang berbeda, Anda dapat meminimalkan kerugian yang disebabkan oleh kesalahan perangkat lunak.

Mengintegrasikan dengan Platform Kontainer yang Dikembangkan Sendiri Menggunakan CRD

APISIX Ingress Controller saat ini mendukung banyak sumber daya CRD, sehingga kami dapat menggunakan sumber daya CRD untuk mengintegrasikan APISIX Ingress Controller dengan platform kontainer kami sendiri. Namun, karena APISIX tidak menyediakan Java Client, kami perlu menggunakan alat pembuatan kode yang disediakan oleh K8s untuk menghasilkan Model dan menggunakan CustomObjectApi untuk mengelola CRD. Objek ApisixRoute dikaitkan dengan aplikasi platform kontainer dan distrukturkan dengan objek inti, memungkinkan staf operasi dan manajer proyek untuk beroperasi di platform kontainer.

Skenario Aplikasi

Autentikasi

Sebelum menggunakan Apache APISIX, kami mengimplementasikan autentikasi berdasarkan gateway Istio, dan setelah bermigrasi ke Apache APISIX, kami memilih untuk menggunakan plugin forward-auth, yang dengan cerdas memindahkan logika autentikasi dan otorisasi ke layanan auth eksternal. Permintaan pengguna diteruskan ke layanan auth melalui gateway, dan ketika layanan auth merespons dengan status non-20x, permintaan asli diblokir dan hasilnya diganti. Dengan cara ini, dimungkinkan untuk mengembalikan laporan kesalahan kustom atau mengarahkan pengguna ke halaman autentikasi jika autentikasi gagal.

Ketika klien mengirim permintaan ke aplikasi, pertama kali diproses oleh plugin forward-auth dari APISIX, dan permintaan diteruskan ke layanan autentikasi eksternal melalui forward-auth, dan hasilnya akhirnya dikembalikan ke gateway APISIX. Jika autentikasi berhasil, klien dapat meminta layanan secara normal. Jika autentikasi gagal, kode kesalahan dikembalikan.

Pengendalian Aliran

Karena karakteristik bisnis perusahaan, ada lima atau enam bulan lalu lintas puncak setiap tahun. Begitu ada terlalu banyak permintaan, kami perlu secara manual memperluas kapasitas, tetapi karena penumpukan permintaan, layanan mungkin tidak dapat dimulai setelah perluasan, yang akan menyebabkan kerusakan avalanche pada seluruh tautan, sehingga kami perlu membatasi aliran dan kecepatan kluster.

Oleh karena itu, kami menggunakan plugin limit-conn, limit-req, dan limit-count dari APISIX untuk membatasi permintaan dan mencegah kerusakan avalanche. Lebih mudah untuk membatasi aliran dan kecepatan dengan memodifikasi plugin, dan karena mekanisme hot-loading APISIX, tidak perlu me-restart plugin saat mengkonfigurasinya, sehingga dapat segera berlaku. Dengan mengendalikan lalu lintas, juga dapat menghentikan beberapa serangan jahat dan melindungi keamanan sistem. Kami juga telah mengimplementasikan HPA (Horizontal Pod Autoscaler) di platform K8s, yang secara otomatis memperluas dan mengecilkan kapasitas begitu jumlah lalu lintas terlalu besar atau terlalu kecil, dengan plugin pembatasan aliran dan kecepatan APISIX untuk menghentikan kerusakan besar-besaran.

Observabilitas

Dalam hal observabilitas, kami saat ini memantau lalu lintas di seluruh platform melalui SkyWalking. Plugin SkyWalking dari APISIX memungkinkan antarmuka langsung dengan platform SkyWalking yang ada, dan UI SkyWalking memudahkan untuk melihat node tautan yang mengkonsumsi kinerja. Selain itu, karena titik pemantauan berada di sisi gateway, sehingga lebih dekat dengan pengguna, lebih mudah untuk memeriksa titik yang memakan waktu.

Dengan plugin kafka-logger, log akses dan kesalahan yang dihasilkan oleh APISIX dapat langsung ditulis ke kluster Apache Kafka. Dengan keuntungan ini, kluster APISIX dapat menskalakan secara stateless dan horizontal tanpa perlu memformat disk, memutar log, atau melakukan operasi lainnya. Jika log disimpan secara lokal, kami perlu melakukan beberapa operasi tambahan dan tidak dapat mencapai penskalaan cepat. Dengan mengirim log ke kluster Apache Kafka, kami juga dapat menganalisis log secara real-time, dan meningkatkan serta mengoptimalkan sistem berdasarkan hasil analisis.

Kesimpulan

Karena APISIX Ingress Controller baru saja diluncurkan, belum banyak skenario aplikasi yang tersedia. Kami akan terus menggali lebih dalam skenario aplikasi dan membawa lebih banyak contoh penggunaan ke komunitas.

Semakin banyak tim yang menggunakan Apache APISIX Ingress Controller di lingkungan produksi. Jika Anda juga menggunakan APISIX Ingress Controller, kami mendorong Anda untuk berbagi kasus penggunaan Anda di komunitas.