Saat meluncurkan kluster Kubernetes untuk aplikasi tertentu, Anda perlu memahami apa yang diajukan oleh aplikasi itu sendiri, bisnis, dan pengembang ke sumber daya ini. Dengan informasi ini, Anda dapat mulai membuat keputusan arsitektural dan, khususnya, memilih pengontrol Ingress tertentu, yang saat ini sudah banyak jumlahnya. Untuk mendapatkan ide dasar tentang opsi yang tersedia tanpa harus melalui banyak artikel/dokumentasi, dll., kami telah menyiapkan ikhtisar ini, termasuk pengontrol Ingress utama (siap produksi).
Kami berharap dapat membantu rekan-rekan dalam memilih solusi arsitektur - setidaknya menjadi titik awal untuk mendapatkan informasi yang lebih detail dan eksperimen praktis. Sebelumnya, kami mempelajari materi serupa lainnya di internet dan, anehnya, tidak menemukan satu pun ulasan yang kurang lebih lengkap, dan yang terpenting - terstruktur -. Jadi mari kita isi celah itu!
kriteria
Pada prinsipnya, untuk membuat perbandingan dan mendapatkan hasil yang bermanfaat, Anda tidak hanya perlu memahami bidang studi, tetapi juga memiliki daftar kriteria khusus yang akan menetapkan vektor penelitian. Tanpa berpura-pura menganalisis semua kemungkinan kasus penggunaan Ingress / Kubernetes, kami mencoba menyoroti persyaratan paling umum untuk pengontrol - bersiaplah bahwa dalam hal apa pun Anda harus mempelajari semua spesifikasi dan detail Anda secara terpisah.
Tetapi saya akan mulai dengan karakteristik yang telah menjadi begitu akrab sehingga diterapkan di semua solusi dan tidak dipertimbangkan:
- penemuan layanan yang dinamis (penemuan layanan);
- penghentian SSL;
- bekerja dengan soket web.
Sekarang untuk poin perbandingan:
Protokol yang didukung
Salah satu kriteria seleksi mendasar. Perangkat lunak Anda mungkin tidak berfungsi pada HTTP standar, atau mungkin perlu bekerja pada beberapa protokol sekaligus. Jika casing Anda tidak standar, pastikan untuk mempertimbangkan faktor ini sehingga Anda tidak perlu mengonfigurasi ulang cluster nanti. Untuk semua pengontrol, daftar protokol yang didukung bervariasi.
perangkat lunak pada intinya
Ada beberapa variasi aplikasi yang menjadi dasar pengontrol. Yang populer adalah nginx, traefik, haproxy, envoy. Dalam kasus umum, ini mungkin tidak banyak berpengaruh pada bagaimana lalu lintas diterima dan ditransmisikan, tetapi selalu berguna untuk mengetahui nuansa dan fitur potensial dari apa yang "di bawah tenda".
Perutean lalu lintas
Atas dasar apa mungkin membuat keputusan tentang arah lalu lintas ke layanan tertentu? Biasanya ini adalah host dan jalur, tetapi ada kemungkinan tambahan.
Namespace dalam sebuah cluster
Namespace (ruang nama) - kemampuan untuk membagi sumber daya secara logis di Kubernetes (misalnya, di atas panggung, produksi, dll.). Ada pengontrol Ingress yang harus diinstal secara terpisah di setiap namespace (dan kemudian dapat mengarahkan lalu lintas hanya ke pod ruang ini). Dan ada yang (dan mayoritas mereka) yang bekerja secara global untuk seluruh cluster - di dalamnya lalu lintas diarahkan ke pod mana pun di cluster, terlepas dari namespace.
Sampel untuk hulu
Bagaimana lalu lintas diarahkan ke contoh sehat aplikasi, layanan? Ada opsi dengan pemeriksaan aktif dan pasif, percobaan ulang, pemutus sirkuit (Untuk detail lebih lanjut, lihat, misalnya, ), penerapan health check sendiri (custom health check), dll. Parameter yang sangat penting jika Anda memiliki persyaratan tinggi untuk ketersediaan dan penghapusan layanan yang gagal secara tepat waktu dari penyeimbangan.
Menyeimbangkan algoritma
Ada banyak pilihan: dari yang tradisional ke eksotis , serta fitur individual seperti .
Otentikasi
Skema otorisasi apa yang didukung pengontrol? Basic, digest, oauth, external-auth - Saya pikir opsi ini seharusnya sudah tidak asing lagi. Ini adalah kriteria penting jika ada banyak loop pengembang (dan/atau hanya pribadi) yang diakses melalui Ingress.
Distribusi lalu lintas
Apakah pengontrol mendukung mekanisme distribusi lalu lintas yang umum digunakan seperti canary rollouts (canary), pengujian A / B, pencerminan lalu lintas (mirroring / shadowing)? Ini adalah subjek yang sangat menyakitkan untuk aplikasi yang membutuhkan manajemen lalu lintas yang akurat dan tepat untuk pengujian produktif, debugging bug produk secara offline (atau dengan kerugian minimal), analisis lalu lintas, dan sebagainya.
Langganan berbayar
Apakah ada opsi berbayar untuk pengontrol, dengan fungsi lanjutan dan/atau dukungan teknis?
Antarmuka pengguna grafis (UI Web)
Apakah ada GUI untuk mengelola konfigurasi pengontrol? Terutama untuk "kepraktisan" dan / atau bagi mereka yang perlu membuat beberapa perubahan pada konfigurasi Ingress, tetapi bekerja dengan templat "mentah" tidak nyaman. Ini bisa berguna jika pengembang ingin melakukan beberapa percobaan dengan lalu lintas dengan cepat.
validasi JWT
Kehadiran validasi bawaan token web JSON untuk otorisasi dan validasi pengguna hingga aplikasi akhir.
Kemungkinan untuk penyesuaian konfigurasi
Ekstensibilitas template dalam arti memiliki mekanisme yang memungkinkan Anda untuk menambahkan arahan, flag, dll. Anda sendiri ke template konfigurasi standar.
Mekanisme perlindungan DDOS dasar
Algoritme batas kecepatan sederhana atau opsi pemfilteran lalu lintas yang lebih kompleks berdasarkan alamat, daftar putih, negara, dll.
Minta jejak
Kemampuan untuk memantau, melacak, dan men-debug permintaan dari Ingress ke layanan/pod tertentu, dan idealnya juga antar layanan/pod.
WAF
Dukungan .
Pengontrol
Daftar pengendali dibentuk berdasarkan и . Kami mengecualikan beberapa dari mereka dari tinjauan karena spesifisitas atau prevalensi rendah (tahap awal perkembangan). Sisanya dibahas di bawah ini. Mari mulai dengan gambaran umum tentang solusi dan lanjutkan dengan tabel ringkasan.
Ingress dari Kubernetes
Situs web:
Lisensi: Apache 2.0
Ini adalah pengontrol resmi untuk Kubernetes dan sedang dikembangkan oleh komunitas. Jelas dari namanya, itu 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 ketika digunakan sebagai pengontrol, opsi ini mungkin yang paling mudah dan termudah untuk dikonfigurasi untuk rata-rata insinyur (dengan pengalaman web).
Ingress oleh NGINX Inc.
Situs web:
Lisensi: Apache 2.0
Produk resmi dari pengembang nginx. Memiliki versi berbayar berdasarkan . Gagasan utamanya adalah tingkat stabilitas yang tinggi, kompatibilitas mundur yang konstan, tidak adanya modul asing dan peningkatan kecepatan yang dinyatakan (dibandingkan dengan pengontrol resmi), yang dicapai karena penolakan Lua.
Versi gratis berkurang secara signifikan, bahkan jika dibandingkan dengan pengontrol resmi (karena kurangnya modul Lua yang sama). Pada saat yang sama, yang berbayar memiliki fungsi tambahan yang cukup luas: metrik waktu nyata, validasi JWT, pemeriksaan kesehatan aktif, dan banyak lagi. Keuntungan penting dibandingkan NGINX Ingress adalah dukungan penuh untuk lalu lintas TCP / UDP (dan juga dalam versi komunitas!). Minus - fitur distribusi lalu lintas, yang, bagaimanapun, "memiliki prioritas tertinggi untuk pengembang", tetapi membutuhkan waktu untuk diterapkan.
Masuknya Kong
Situs web:
Lisensi: Apache 2.0
Produk yang dikembangkan oleh Kong Inc. dalam dua versi: komersial dan gratis. Berdasarkan nginx, yang telah diperluas dengan sejumlah besar modul Lua.
Awalnya, ini difokuskan pada pemrosesan dan perutean permintaan API, mis. sebagai API Gateway, tetapi saat ini telah menjadi pengontrol Ingress yang lengkap. Keuntungan utama: banyak modul tambahan (termasuk dari pengembang pihak ketiga) yang mudah dipasang dan dikonfigurasi dan dengan bantuan yang diimplementasikan berbagai fitur tambahan. Namun, fungsi bawaan sudah menawarkan banyak kemungkinan. Konfigurasi pekerjaan dilakukan menggunakan sumber daya CRD.
Fitur penting dari produk - bekerja dalam kontur yang sama (bukan lintas-nama) adalah topik yang kontroversial: bagi sebagian orang hal itu akan tampak seperti kerugian (Anda harus membuat entitas untuk setiap kontur), dan bagi seseorang itu adalah fitur ( BоTingkat isolasi yang lebih besar, seperti jika salah satu pengontrol rusak, maka masalahnya hanya terbatas pada sirkuitnya saja).
Traefik
Situs web:
Lisensi: MIT
Proksi yang awalnya dibuat untuk bekerja dengan perutean permintaan untuk layanan mikro dan lingkungan dinamisnya. Karenanya, banyak fitur berguna: memperbarui konfigurasi tanpa me-reboot sama sekali, mendukung sejumlah besar metode penyeimbangan, antarmuka web, penerusan metrik, dukungan untuk berbagai protokol, REST API, rilis canary, dan banyak lagi. Fitur bagus lainnya adalah dukungan untuk sertifikat Let's Encrypt out of the box. Kerugiannya adalah untuk mengatur ketersediaan tinggi (HA), pengontrol perlu memasang dan menyambungkan penyimpanan KV-nya sendiri.
HAProxy
Situs web:
Lisensi: Apache 2.0
HAProxy 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 berdasarkan DNS, konfigurasi dinamis menggunakan API. Sangat menarik untuk menyesuaikan sepenuhnya template konfigurasi dengan mengganti CM, serta kemampuan untuk menggunakan fungsi perpustakaan Sprig di dalamnya. Secara umum, penekanan utama dari solusi ini adalah pada kecepatan tinggi, optimalisasi dan efisiensi sumber daya yang dikonsumsi. Keuntungan dari pengontrol adalah dukungan dari sejumlah metode penyeimbangan yang berbeda.
Voyager
Situs web:
Lisensi: Apache 2.0
Berdasarkan pengontrol HAproxy, yang diposisikan sebagai solusi universal yang mendukung berbagai fitur pada sejumlah besar penyedia. Peluang ditawarkan untuk menyeimbangkan lalu lintas pada L7 dan L4, dan menyeimbangkan lalu lintas TCP L4 secara keseluruhan dapat disebut sebagai salah satu fitur utama dari solusi tersebut.
Kontur
Situs web:
Lisensi: Apache 2.0
Solusi ini tidak hanya berdasarkan Utusan: ini dikembangkan oleh bersama dengan penulis proxy populer ini. Fitur penting adalah kemampuan untuk memisahkan kontrol sumber daya Ingress menggunakan sumber daya IngressRoute CRD. Untuk organisasi dengan banyak tim pengembangan yang menggunakan cluster yang sama, ini membantu memaksimalkan keamanan bekerja dengan lalu lintas di loop tetangga dan melindunginya dari kesalahan saat mengubah sumber daya Ingress.
Ini juga menawarkan serangkaian metode penyeimbangan yang diperluas (ada pencerminan permintaan, pengulangan otomatis, membatasi tingkat permintaan, dan banyak lagi), pemantauan terperinci arus lalu lintas dan kegagalan. Mungkin bagi seseorang itu akan menjadi kekurangan yang signifikan kurangnya dukungan untuk sesi yang lengket (meskipun pekerjaan ).
Masuknya
Situs web:
Lisensi: Apache 2.0
Solusi mesh layanan komprehensif yang tidak hanya pengontrol Ingress yang mengelola lalu lintas masuk dari luar, tetapi juga mengontrol semua lalu lintas di dalam klaster. Di bawah tenda, Utusan digunakan sebagai proxy sespan untuk setiap layanan. Intinya, ini adalah kombinasi besar yang "dapat melakukan apa saja", dan ide utamanya adalah pengelolaan maksimum, ekstensibilitas, keamanan, dan transparansi. Dengannya, Anda dapat menyempurnakan perutean lalu lintas, otorisasi akses antar layanan, penyeimbangan, pemantauan, rilis canary, dan banyak lagi. Baca lebih lanjut tentang Istio dalam rangkaian artikel "'.
Duta besar
Situs web:
Lisensi: Apache 2.0
Solusi lain berdasarkan Utusan. Ini memiliki versi gratis dan komersial. Ini diposisikan sebagai "sepenuhnya asli Kubernetes", yang memberikan keuntungan yang sesuai (integrasi yang erat dengan metode dan entitas kluster K8s).
Tabel perbandingan
Jadi, puncak dari artikel ini adalah tabel besar ini:
Ini dapat diklik untuk melihat lebih dekat, dan juga tersedia dalam format .
untuk meringkas
Tujuan dari artikel ini adalah untuk memberikan pemahaman yang lebih lengkap (namun, tidak berarti lengkap!) tentang pilihan apa yang harus diambil dalam kasus khusus Anda. Seperti biasa, setiap controller memiliki kelebihan dan kekurangannya masing-masing…
Ingress klasik dari Kubernetes bagus untuk ketersediaan dan pembuktiannya, fitur yang cukup kaya - secara umum, itu harus "cukup untuk dilihat". Namun, jika ada peningkatan persyaratan untuk stabilitas, tingkat fitur, dan pengembangan, Anda harus memperhatikan Ingress dengan NGINX Plus dan langganan berbayar. Kong memiliki kumpulan plugin terkaya (dan, karenanya, peluang yang mereka berikan), dan dalam versi berbayar bahkan ada lebih banyak plugin. Ini memiliki banyak peluang untuk bekerja sebagai API Gateway, konfigurasi dinamis berdasarkan sumber daya CRD, serta layanan Kubernetes dasar.
Dengan persyaratan yang meningkat untuk metode penyeimbangan dan otorisasi, lihat Traefik dan HAProxy. Ini adalah proyek Open Source, terbukti selama bertahun-tahun, sangat stabil dan berkembang secara aktif. Kontur telah keluar selama beberapa tahun sekarang, tetapi masih terlihat terlalu muda dan hanya memiliki fitur dasar yang ditambahkan di atas Utusan. Jika ada persyaratan untuk keberadaan / penyematan WAF di depan aplikasi, Anda harus memperhatikan Ingress yang sama dari Kubernetes atau HAProxy.
Dan yang terkaya dalam hal fitur adalah produk yang dibangun di atas Envoy, terutama Istio. Tampaknya menjadi solusi komprehensif yang "dapat melakukan apa saja", yang, bagaimanapun, juga berarti ambang masuk yang jauh lebih tinggi untuk konfigurasi / peluncuran / administrasi daripada solusi lain.
Kami telah memilih dan tetap menggunakan Ingress dari Kubernetes sebagai pengontrol standar, yang mencakup 80-90% kebutuhan. Ini cukup andal, mudah dikonfigurasi dan diperluas. Secara umum, jika tidak ada persyaratan khusus, itu harus sesuai dengan sebagian besar cluster / aplikasi. Dari produk universal dan relatif sederhana yang sama, Traefik dan HAProxy dapat direkomendasikan.
PS
Baca juga di blog kami:
- "Kembali ke layanan mikro dengan Istio": , , ;
- «»;
- «'.
Sumber: www.habr.com