Saat memulai cluster Kubernetes untuk aplikasi tertentu, Anda harus memahami persyaratan apa yang diajukan aplikasi itu sendiri, bisnis, dan pengembang untuk sumber daya ini. Jika Anda memiliki informasi ini, Anda dapat mulai membuat keputusan arsitektur dan, khususnya, untuk memilih pengontrol Ingress tertentu, yang sudah ada dalam jumlah besar hari ini. Untuk mendapatkan ide dasar tentang opsi yang tersedia tanpa harus mempelajari banyak artikel / dokumentasi, dll., Kami menyiapkan tinjauan ini dengan memasukkan pengendali masuk (siap produksi) utama di dalamnya.
Kami berharap ini akan membantu kolega dalam memilih solusi arsitektur - setidaknya, akan menjadi titik awal untuk informasi yang lebih rinci dan eksperimen praktis. Sebelumnya, kami mempelajari materi serupa lainnya di jaringan dan, anehnya, tidak menemukan satu pun yang lebih lengkap atau kurang lengkap, dan yang paling penting - terstruktur - ulasan. Jadi, isi celah ini!
Kriteria
Untuk membuat perbandingan pada prinsipnya dan mendapatkan hasil yang bermanfaat, Anda perlu memahami tidak hanya bidang subjek, tetapi juga memiliki daftar kriteria tertentu yang akan menentukan vektor penelitian. Tanpa berpura-pura menganalisis semua kemungkinan kasus menggunakan Ingress / Kubernetes, kami mencoba menyoroti persyaratan paling umum untuk pengontrol - bersiaplah bahwa Anda harus mempelajari semua spesifikasi dan rincian Anda dalam kasus apa pun secara terpisah.
Tetapi saya akan mulai dengan karakteristik yang telah menjadi begitu akrab sehingga diterapkan dalam semua keputusan dan tidak dipertimbangkan:
- penemuan layanan yang dinamis (penemuan layanan);
- Terminasi SSL;
- bekerja dengan soket web.
Sekarang tentang poin perbandingan:
Protokol yang didukung
Salah satu kriteria mendasar untuk seleksi. Perangkat lunak Anda mungkin tidak berfungsi pada HTTP standar, atau mungkin memerlukan kerja pada banyak protokol sekaligus. Jika kasing Anda tidak standar, pastikan untuk memperhitungkan faktor ini sehingga Anda tidak perlu mengkonfigurasi ulang gugus nanti. Untuk semua pengontrol, daftar protokol yang didukung bervariasi.
Berbasis perangkat lunak
Ada beberapa opsi aplikasi yang menjadi dasar pengontrol. Yang populer adalah nginx, traefik, haproxy, utusan. Dalam kasus umum, ini mungkin tidak mempengaruhi cara lalu lintas diterima dan ditransmisikan, tetapi selalu berguna untuk mengetahui nuansa dan fitur potensial dari apa yang "di bawah tenda".
Routing lalu lintas
Atas dasar apa kita dapat memutuskan arah lalu lintas ke layanan tertentu? Ini biasanya host dan path, tetapi ada fitur tambahan.
Cluster Namespace
Namespace (namespace) - kemampuan untuk membagi sumber daya secara logis di Kubernetes (misalnya, di atas panggung, produksi, dll.). Ada pengontrol Ingress yang harus ditetapkan secara terpisah di setiap namespace (dan kemudian
hanya bisa mengarahkan lalu lintas ke pod ruang ini). Dan ada orang-orang (dan mayoritas mereka) yang bekerja secara global pada seluruh cluster - di dalamnya lalu lintas diarahkan ke pod apa pun dari cluster, terlepas dari namespace.
Sampel untuk hulu
Bagaimana lalu lintas diarahkan ke contoh aplikasi, layanan yang sehat? Ada beberapa opsi dengan pemeriksaan aktif dan pasif, percobaan ulang, pemutus sirkuit
(untuk lebih jelasnya lihat, misalnya, dalam artikel tentang Istio ) , implementasi pemeriksaan kesehatan khusus, dll. Parameter yang sangat penting jika Anda memiliki persyaratan tinggi untuk aksesibilitas dan penarikan tepat waktu dari layanan yang gagal dari saldo.
Algoritma balancing
Ada banyak pilihan: dari
round-robin tradisional ke yang eksotis seperti
rdp-cookies , serta beberapa fitur seperti
sesi sticky .
Otentikasi
Skema otorisasi apa yang didukung pengendali? Basic, digest, oauth, external-auth - Saya pikir opsi ini sudah tidak asing lagi. Ini adalah kriteria penting jika Anda menggunakan banyak sirkuit untuk pengembang (dan / atau yang hanya ditutup) yang diakses melalui Ingress.
Distribusi lalu lintas
Apakah pengontrol mendukung mekanisme yang biasa digunakan untuk distribusi lalu lintas seperti peluncuran kenari, pengujian A / B, lalu lintas mirroring (mirroring / shadowing)? Ini adalah masalah yang sangat parah untuk aplikasi yang membutuhkan manajemen lalu lintas yang akurat dan akurat untuk pengujian produktif, men-debug kesalahan produk yang tidak ada dalam pertempuran (atau dengan kerugian minimal), analisis lalu lintas, dll.
Berlangganan berbayar
Apakah ada opsi berbayar untuk pengontrol, dengan fungsionalitas tingkat lanjut dan / atau dukungan teknis?
Antarmuka Pengguna Grafis (UI Web)
Apakah ada antarmuka grafis untuk mengontrol konfigurasi controller? Pada dasarnya, untuk "handiness" dan / atau bagi mereka yang perlu membuat beberapa perubahan pada konfigurasi Ingress, tetapi bekerja dengan templat "raw" tidak nyaman. Mungkin berguna jika pengembang ingin melakukan percobaan dengan lalu lintas dengan cepat.
Validasi JWT
Kehadiran verifikasi JSON bawaan dari token web untuk otorisasi dan validasi pengguna dari aplikasi akhir.
Fitur untuk kustomisasi konfigurasi
Ekstensibilitas templat dalam arti memiliki mekanisme untuk menambahkan arahan, bendera, dll. Sendiri ke templat konfigurasi standar
Mekanisme perlindungan DDOS dasar
Algoritme batas laju sederhana atau opsi yang lebih canggih untuk memfilter lalu lintas berdasarkan alamat, daftar putih, negara, dll.
Lacak Permintaan
Kemungkinan untuk mengamati, melacak dan men-debug permintaan dari Ingress ke layanan / pod tertentu, dan idealnya, di antara layanan / pod juga.
WAF
Dukungan untuk
firewall aplikasi .
Pengontrol Ingress
Daftar pengontrol didasarkan pada
dokumentasi Kubernetes resmi dan
tabel ini . Kami mengeluarkan beberapa dari mereka dari tinjauan karena kekhususan atau prevalensi rendah (tahap awal pengembangan). Yang tersisa dibahas di bawah ini. Kami mulai dengan deskripsi umum solusi dan melanjutkan dengan tabel pivot.
Ingress oleh Kubernetes
Situs web: github.com/kubernetes/ingress-nginxLisensi: Apache 2.0Ini adalah pengontrol resmi untuk Kubernetes, yang sedang dikembangkan oleh komunitas. Jelas dari namanya, ini didasarkan pada nginx dan dilengkapi dengan serangkaian plugin Lua yang berbeda yang digunakan untuk mengimplementasikan fitur tambahan. Karena popularitas nginx itu sendiri dan modifikasi minimal untuk itu ketika digunakan sebagai pengontrol, opsi ini mungkin merupakan insinyur konfigurasi rata-rata konfigurasi yang paling sederhana dan paling dapat dipahami (dengan pengalaman di web).
Ingress oleh NGINX Inc
Situs web: github.com/nginxinc/kubernetes-ingressLisensi: Apache 2.0Produk resmi pengembang nginx. Ini memiliki versi berbayar berdasarkan
NGINX Plus . Gagasan utamanya adalah tingkat stabilitas yang tinggi, kompatibilitas mundur yang konstan, tidak adanya modul tambahan dan kecepatan yang dinyatakan meningkat (dibandingkan dengan pengontrol resmi) yang dicapai karena penolakan Lua.
Versi gratis telah berkurang secara signifikan, termasuk bahkan ketika dibandingkan dengan pengontrol resmi (karena kurangnya Lua-modul yang sama). Dibayar pada saat yang sama memiliki fungsi tambahan yang cukup luas: metrik real-time, validasi JWT, pemeriksaan kesehatan aktif, dan banyak lagi. Keuntungan penting dari NGINX Ingress adalah dukungan penuh untuk lalu lintas TCP / UDP (dan juga dalam versi komunitas!). Kelemahannya adalah
kurangnya fitur untuk distribusi lalu lintas, yang, bagaimanapun, "memiliki prioritas tertinggi untuk pengembang," tetapi butuh waktu untuk mengimplementasikannya.
Kong Ingress
Situs web: github.com/Kong/kubernetes-ingress-controllerLisensi: Apache 2.0Produk yang dikembangkan oleh Kong Inc. dalam dua versi: komersial dan gratis. Ini didasarkan pada nginx, kemampuan yang diperluas oleh sejumlah besar modul pada Lua.
Awalnya, ini difokuskan pada pemrosesan dan perutean permintaan API, mis. seperti API Gateway, tetapi saat ini telah menjadi pengontrol Ingress penuh. Keuntungan utama: banyak modul tambahan (termasuk dari pengembang pihak ketiga) yang mudah dipasang dan dikonfigurasikan dan yang dengannya berbagai fitur tambahan diimplementasikan. Namun, fitur bawaan sudah menawarkan banyak fitur. Konfigurasi pekerjaan dilakukan menggunakan sumber daya CRD.
Fitur penting dari produk - bekerja dalam sirkuit yang sama (alih-alih lintas-nama tempat) adalah topik yang kontroversial: bagi sebagian orang hal itu akan menjadi kelemahan (Anda harus menghasilkan entitas untuk setiap sirkuit), dan untuk seseorang itu adalah fitur (tingkat isolasi yang lebih tinggi, karena jika satu pengontrol rusak, maka masalahnya terbatas pada satu rangkaian saja).
Traefik
Situs web: github.com/containous/traefikLisensi: MITProxy yang awalnya dibuat untuk bekerja dengan perutean permintaan untuk layanan microser dan lingkungan dinamisnya. Oleh karena itu, banyak fitur yang berguna: memperbarui konfigurasi sepenuhnya tanpa reboot, mendukung sejumlah besar metode balancing, antarmuka web, metrik penerusan, mendukung berbagai protokol, REST API, rilis kenari, dan banyak lagi. Fitur yang bagus juga mendukung sertifikat Mari Enkripsi di luar kotak. Kerugiannya adalah bahwa untuk organisasi ketersediaan tinggi (HA), pengontrol perlu menginstal dan menghubungkan penyimpanan KV-nya sendiri.
HAProxy
Situs web: github.com/jcmoraisjr/haproxy-ingressLisensi: Apache 2.0HAProxy telah lama dikenal sebagai proxy dan penyeimbang lalu lintas. Sebagai bagian dari kluster Kubernetes, ia menawarkan pembaruan konfigurasi "lunak" (tanpa kehilangan lalu lintas), penemuan layanan berbasis DNS, konfigurasi dinamis menggunakan API. Kustomisasi penuh templat konfigurasi dengan cara mengganti CM'a, serta kemungkinan menggunakan fungsi pustaka Sprig di dalamnya, dapat menjadi menarik. Secara umum, fokus utama dari solusi adalah pada kecepatan tinggi, optimisme dan efisiensinya dalam sumber daya yang dikonsumsi. Keuntungan dari pengontrol adalah dukungan dari sejumlah catatan metode balancing yang berbeda.
Voyager
Situs web: github.com/appscode/voyagerLisensi: Apache 2.0Pengontrol berbasis HAproxy, yang diposisikan sebagai solusi universal yang mendukung kapabilitas luas pada sejumlah besar penyedia. Peluang diusulkan untuk menyeimbangkan lalu lintas pada L7 dan L4, dan menyeimbangkan lalu lintas TCP L4 secara keseluruhan dapat disebut salah satu fitur kunci dari solusi.
Kontur
Situs web: github.com/heptio/contourLisensi: Apache 2.0Utusan tidak hanya meletakkan dasar dari solusi ini: itu dikembangkan
bersama dengan penulis proksi populer ini. Fitur penting adalah kemampuan untuk membagi manajemen sumber daya Ingress menggunakan sumber daya CRD IngressRoute. Untuk organisasi dengan banyak tim pengembangan yang menggunakan satu kluster, ini membantu memaksimalkan keselamatan lalu lintas di sirkuit tetangga dan melindunginya dari kesalahan saat mengubah sumber daya Ingress.
Ia juga menawarkan serangkaian metode penyeimbangan (ada mirroring dari permintaan, auto-retries, pembatasan pada tingkat permintaan, dan banyak lagi), pemantauan terperinci dari arus lalu lintas dan kegagalan. Mungkin bagi sebagian orang hal itu akan menjadi kelemahan yang signifikan terhadap kurangnya dukungan untuk sesi-sesi lengket (meskipun pekerjaan sedang
berlangsung ).
Isstio masuknya
Situs web: istio.io/docs/tasks/traffic-management/ingressLisensi: Apache 2.0Solusi mesh layanan komprehensif, yang tidak hanya pengontrol Ingress yang mengontrol lalu lintas masuk dari luar, tetapi juga mengontrol semua lalu lintas di dalam kluster. Di bawah Kap, Utusan digunakan sebagai proxy sespan untuk setiap layanan. Intinya, ini adalah kombinasi besar yang "dapat melakukan apa saja", dan gagasan utamanya adalah pengelolaan yang maksimal, ekstensibilitas, keamanan, dan transparansi. Dengan itu, Anda dapat menyempurnakan perutean lalu lintas, otorisasi akses antara layanan, penyeimbangan, pemantauan, rilis kenari dan banyak lagi. Baca lebih lanjut tentang Istio di
Back to Microservices dengan serangkaian artikel
Istio .
Duta Besar
Situs web: github.com/datawire/ambassyLisensi: Apache 2.0Solusi lain berdasarkan Utusan. Memiliki versi gratis dan komersial. Ini diposisikan sebagai "sepenuhnya asli untuk Kubernetes", yang membawa keuntungan terkait (integrasi yang erat dengan metode dan entitas dari cluster K8s).
Tabel perbandingan
Jadi, klimaks dari artikel ini adalah tabel besar ini:
Dapat diklik untuk tampilan yang lebih detail, dan juga tersedia dalam format
Google Sheets .
Untuk meringkas
Tujuan artikel ini adalah untuk memberikan pemahaman yang lebih lengkap (namun, sama sekali tidak lengkap!) Dari pilihan apa yang harus diambil dalam kasus khusus Anda. Seperti biasa, setiap pengontrol memiliki kelebihan dan kekurangan ...
Kubernetes Ingress klasik baik untuk aksesibilitas dan keasliannya, cukup kaya fitur - secara umum, itu harus "cukup untuk mata." Namun, jika ada peningkatan persyaratan untuk stabilitas, tingkat fitur dan pengembangan, ada baiknya memperhatikan Ingress dengan NGINX Plus dan berlangganan berbayar. Kong memiliki banyak plugin (dan, dengan demikian, kemampuan yang mereka berikan), dan dalam versi berbayar, ada lebih banyak lagi. Ia memiliki banyak peluang untuk bekerja sebagai API Gateway, mengonfigurasi secara dinamis berdasarkan sumber daya CRD, serta layanan dasar Kubernetes.
Dengan meningkatnya persyaratan untuk menyeimbangkan dan metode otorisasi, lihat Traefik dan HAProxy. Ini adalah proyek Open Source, terbukti selama bertahun-tahun, sangat stabil dan berkembang secara aktif. Contour telah ada selama beberapa tahun, tetapi masih terlihat terlalu muda dan hanya memiliki fitur dasar yang ditambahkan di atas Utusan. Jika ada persyaratan untuk kehadiran / embedding WAF sebelum aplikasi, Anda harus memperhatikan Ingress yang sama dari Kubernetes atau HAProxy.
Dan yang paling kaya dalam fitur adalah produk yang dibangun atas dasar Utusan, terutama Istio. Tampaknya menjadi solusi kompleks yang "dapat melakukan apa saja", yang, bagaimanapun, juga berarti ambang batas yang jauh lebih tinggi untuk memasukkan konfigurasi / peluncuran / administrasi daripada solusi lain.
Kami telah memilih dan masih menggunakan Kubernetes Ingress, yang mencakup 80-90% dari kebutuhan, sebagai pengontrol standar. Ini cukup dapat diandalkan, mudah dikonfigurasi, diperluas. Dalam kasus umum, dengan tidak adanya persyaratan khusus, harus sesuai dengan sebagian besar cluster / aplikasi. Dari produk serbaguna dan relatif sama yang sama, Traefik dan HAProxy dapat direkomendasikan.
PS
Baca juga di blog kami: