Apabila melancarkan gugusan Kubernetes untuk aplikasi tertentu, anda perlu memahami perkara yang ditimbulkan oleh aplikasi itu sendiri, perniagaan dan pembangun kepada sumber ini. Dengan maklumat ini, anda boleh mula membuat keputusan seni bina dan, khususnya, memilih pengawal Ingress tertentu, yang sudah ada sejumlah besar hari ini. Untuk mendapatkan idea asas tentang pilihan yang tersedia tanpa perlu melalui banyak artikel / dokumentasi, dsb., kami telah menyediakan gambaran keseluruhan ini, termasuk pengawal Ingress utama (siap pengeluaran).
Kami berharap ia akan membantu rakan sekerja dalam memilih penyelesaian seni bina - sekurang-kurangnya ia akan menjadi titik permulaan untuk mendapatkan maklumat yang lebih terperinci dan eksperimen praktikal. Sebelum ini, kami mengkaji bahan lain yang serupa di internet dan, anehnya, tidak menemui satu pun lebih kurang lengkap, dan yang paling penting - berstruktur - semakan. Jadi mari kita penuhi jurang itu!
kriteria
Pada dasarnya, untuk membuat perbandingan dan mendapatkan sebarang hasil yang berguna, anda perlu memahami bukan sahaja kawasan subjek, tetapi juga mempunyai senarai kriteria khusus yang akan menetapkan vektor penyelidikan. Tanpa berpura-pura menganalisis semua kemungkinan kes penggunaan Ingress / Kubernetes, kami cuba menyerlahkan keperluan paling umum untuk pengawal - bersedialah bahawa dalam apa jua keadaan anda perlu mengkaji semua butiran dan butiran anda secara berasingan.
Tetapi saya akan mulakan dengan ciri-ciri yang telah menjadi sangat biasa sehingga ia dilaksanakan dalam semua penyelesaian dan tidak dipertimbangkan:
- penemuan perkhidmatan yang dinamik (penemuan perkhidmatan);
- Penamatan SSL;
- bekerja dengan soket web.
Sekarang untuk mata perbandingan:
Protokol yang disokong
Salah satu kriteria pemilihan asas. Perisian anda mungkin tidak berfungsi pada HTTP standard, atau mungkin memerlukan kerja pada berbilang protokol serentak. Jika kes anda tidak standard, pastikan anda mengambil kira faktor ini supaya anda tidak perlu mengkonfigurasi semula kluster kemudian. Untuk semua pengawal, senarai protokol yang disokong berbeza-beza.
perisian pada teras
Terdapat beberapa variasi aplikasi yang menjadi asas kepada pengawal. Yang popular ialah nginx, traefik, haproxy, utusan. Dalam kes umum, ia mungkin tidak mempunyai banyak kesan ke atas cara trafik diterima dan dihantar, tetapi sentiasa berguna untuk mengetahui potensi nuansa dan ciri apa yang "di bawah tudung".
Laluan lalu lintas
Atas dasar apa yang mungkin untuk membuat keputusan tentang arah lalu lintas ke perkhidmatan tertentu? Biasanya ini adalah hos dan laluan, tetapi terdapat kemungkinan tambahan.
Ruang nama dalam kelompok
Ruang nama (ruang nama) - keupayaan untuk membahagikan sumber secara logik dalam Kubernetes (contohnya, di atas pentas, pengeluaran, dll.). Terdapat pengawal Ingress yang mesti dipasang secara berasingan dalam setiap ruang nama (dan kemudian ia boleh mengarahkan trafik sahaja ke buah ruang ini). Dan terdapat mereka (dan majoriti jelas mereka) yang berfungsi secara global untuk keseluruhan kluster - di dalamnya trafik dihalakan ke mana-mana pod kluster, tanpa mengira ruang nama.
Sampel untuk hulu
Bagaimanakah trafik dihalakan kepada contoh aplikasi, perkhidmatan yang sihat? Terdapat pilihan dengan semakan aktif dan pasif, cuba semula, pemutus litar (Untuk butiran lanjut, lihat, sebagai contoh, ), pemeriksaan kesihatan tersuai, dsb. Parameter yang sangat penting jika anda mempunyai keperluan yang tinggi untuk ketersediaan dan penyingkiran perkhidmatan yang gagal tepat pada masanya daripada pengimbangan.
Algoritma pengimbangan
Terdapat banyak pilihan: dari tradisional kepada yang eksotik , serta ciri individu seperti .
Pengesahan
Apakah skim kebenaran yang disokong oleh pengawal? Asas, digest, oauth, external-auth - Saya rasa pilihan ini sepatutnya biasa. Ini merupakan kriteria penting jika terdapat banyak gelung pembangun (dan/atau hanya peribadi) yang diakses melalui Ingress.
Pengagihan trafik
Adakah pengawal menyokong mekanisme pengagihan trafik yang biasa digunakan seperti pelancaran kenari (kanari), ujian A/B, pencerminan trafik (pencerminan/pembayangan)? Ini adalah subjek yang sangat menyakitkan untuk aplikasi yang memerlukan pengurusan trafik yang tepat dan tepat untuk ujian yang produktif, menyahpepijat pepijat produk di luar talian (atau dengan kerugian yang minimum), analisis trafik dan sebagainya.
Langganan berbayar
Adakah terdapat pilihan berbayar untuk pengawal, dengan fungsi lanjutan dan / atau sokongan teknikal?
Antara muka pengguna grafik (UI Web)
Adakah terdapat GUI untuk mengurus konfigurasi pengawal? Terutamanya untuk "kemampuan" dan / atau bagi mereka yang perlu membuat beberapa perubahan pada konfigurasi Ingress'a, tetapi bekerja dengan templat "mentah" adalah menyusahkan. Ia boleh berguna jika pembangun ingin menjalankan beberapa percubaan dengan trafik dengan cepat.
pengesahan JWT
Kehadiran pengesahan terbina dalam token web JSON untuk kebenaran dan pengesahan pengguna ke aplikasi akhir.
Kemungkinan untuk penyesuaian konfigurasi
Kebolehlanjutan templat dalam erti kata mempunyai mekanisme yang membolehkan anda menambah arahan, bendera, dll. anda sendiri pada templat konfigurasi standard.
Mekanisme perlindungan asas DDOS
Algoritma had kadar mudah atau pilihan penapisan trafik yang lebih kompleks berdasarkan alamat, senarai putih, negara, dsb.
Minta jejak
Keupayaan untuk memantau, menjejak dan menyahpepijat permintaan daripada Ingresses kepada perkhidmatan / pod tertentu, dan idealnya antara perkhidmatan / pod juga.
WAF
Sokongan .
Pengawal
Senarai pengawal telah dibentuk berdasarkan ΠΈ . Kami mengecualikan sebahagian daripada mereka daripada semakan kerana kekhususan atau kelaziman yang rendah (peringkat awal pembangunan). Selebihnya dibincangkan di bawah. Mari kita mulakan dengan penerangan umum tentang penyelesaian dan teruskan dengan jadual ringkasan.
Ingress dari Kubernetes
Laman web:
Lesen: Apache 2.0
Ini ialah pengawal rasmi untuk Kubernetes dan sedang dibangunkan oleh komuniti. Jelas sekali dari namanya, ia berdasarkan nginx dan dilengkapi dengan set pemalam Lua yang berbeza yang digunakan untuk melaksanakan ciri tambahan. Disebabkan populariti nginx itu sendiri dan pengubahsuaian minimum padanya apabila digunakan sebagai pengawal, pilihan ini mungkin yang paling mudah dan paling mudah untuk dikonfigurasikan untuk jurutera biasa (dengan pengalaman web).
Ingress oleh NGINX Inc.
Laman web:
Lesen: Apache 2.0
Produk rasmi pembangun nginx. Mempunyai versi berbayar berdasarkan . Idea utama ialah tahap kestabilan yang tinggi, keserasian ke belakang yang berterusan, ketiadaan sebarang modul luar dan kelajuan yang diisytiharkan meningkat (berbanding dengan pengawal rasmi), dicapai kerana penolakan Lua.
Versi percuma dikurangkan dengan ketara, termasuk walaupun dibandingkan dengan pengawal rasmi (kerana kekurangan modul Lua yang sama). Pada masa yang sama, yang berbayar mempunyai fungsi tambahan yang agak luas: metrik masa nyata, pengesahan JWT, pemeriksaan kesihatan aktif dan banyak lagi. Kelebihan penting berbanding NGINX Ingress ialah sokongan penuh untuk trafik TCP / UDP (dan dalam versi komuniti juga!). Tolak - ciri pengedaran trafik, yang, bagaimanapun, "mempunyai keutamaan tertinggi untuk pembangun," tetapi mengambil masa untuk dilaksanakan.
Kong Ingress
Laman web:
Lesen: Apache 2.0
Produk yang dibangunkan oleh Kong Inc. dalam dua versi: komersial dan percuma. Berdasarkan nginx, yang telah dilanjutkan dengan sejumlah besar modul Lua.
Pada mulanya, ia tertumpu pada pemprosesan dan penghalaan permintaan API, i.e. sebagai Gateway API, tetapi pada masa ini ia telah menjadi pengawal Ingress sepenuhnya. Kelebihan utama: banyak modul tambahan (termasuk modul daripada pembangun pihak ketiga) yang mudah dipasang dan dikonfigurasikan dan dengan bantuan yang pelbagai ciri tambahan dilaksanakan. Walau bagaimanapun, fungsi terbina dalam sudah menawarkan banyak kemungkinan. Konfigurasi kerja dilakukan menggunakan sumber CRD.
Ciri penting produk - bekerja dalam kontur yang sama (bukannya ruang silang nama) ialah topik yang kontroversi: bagi sesetengah orang ia akan kelihatan seperti satu kelemahan (anda perlu menghasilkan entiti untuk setiap kontur), dan bagi seseorang ia adalah ciri ( bΠΎTahap pengasingan yang lebih tinggi, seperti jika satu pengawal rosak, maka masalahnya terhad kepada litar sahaja).
Traefik
Laman web:
Lesen: MIT
Proksi yang pada asalnya dicipta untuk berfungsi dengan penghalaan permintaan untuk perkhidmatan mikro dan persekitaran dinamiknya. Oleh itu, banyak ciri berguna: mengemas kini konfigurasi tanpa but semula sama sekali, sokongan untuk sejumlah besar kaedah pengimbangan, antara muka web, pemajuan metrik, sokongan untuk pelbagai protokol, REST API, keluaran kenari dan banyak lagi. Satu lagi ciri menarik ialah sokongan untuk sijil Let's Encrypt di luar kotak. Kelemahannya ialah untuk mengatur ketersediaan tinggi (HA), pengawal perlu memasang dan menyambung storan KVnya sendiri.
HAProxy
Laman web:
Lesen: Apache 2.0
HAProxy telah lama dikenali sebagai proksi dan pengimbang trafik. Sebagai sebahagian daripada kluster Kubernetes, ia menawarkan kemas kini konfigurasi "lembut" (tanpa kehilangan trafik), penemuan perkhidmatan berdasarkan DNS, konfigurasi dinamik menggunakan API. Ia boleh menjadi menarik untuk menyesuaikan sepenuhnya templat konfigurasi dengan menggantikan CM, serta keupayaan untuk menggunakan fungsi perpustakaan Sprig di dalamnya. Secara umum, penekanan utama penyelesaian adalah pada kelajuan tinggi, pengoptimuman dan kecekapan dalam sumber yang digunakan. Kelebihan pengawal adalah sokongan nombor rekod kaedah pengimbangan yang berbeza.
Voyager
Laman web:
Lesen: Apache 2.0
Berdasarkan pengawal HAproxy, yang diletakkan sebagai penyelesaian universal yang menyokong pelbagai ciri pada sejumlah besar penyedia. Peluang ditawarkan untuk mengimbangi trafik pada L7 dan L4, dan mengimbangi trafik TCP L4 secara keseluruhan boleh dipanggil salah satu ciri utama penyelesaian.
Kontur
Laman web:
Lesen: Apache 2.0
Penyelesaian ini bukan sahaja berdasarkan Utusan: ia dibangunkan oleh bersama-sama dengan pengarang proksi popular ini. Ciri penting ialah keupayaan untuk memisahkan kawalan sumber Ingress menggunakan sumber CRD IngressRoute. Bagi organisasi yang mempunyai banyak pasukan pembangunan yang menggunakan kluster yang sama, ini membantu memaksimumkan keselamatan bekerja dengan trafik dalam gelung jiran dan melindungi mereka daripada ralat semasa menukar sumber Ingress.
Ia juga menawarkan set kaedah pengimbangan lanjutan (terdapat pencerminan permintaan, ulangan automatik, pengehadan kadar permintaan dan banyak lagi), pemantauan terperinci aliran trafik dan kegagalan. Mungkin bagi seseorang ia akan menjadi kelemahan yang ketara kekurangan sokongan untuk sesi melekit (walaupun kerja ).
Istio Ingress
Laman web:
Lesen: Apache 2.0
Penyelesaian rangkaian perkhidmatan komprehensif yang bukan sahaja pengawal Ingress yang mengurus trafik masuk dari luar, tetapi juga mengawal semua trafik dalam kelompok. Di bawah tudung, Utusan digunakan sebagai proksi kereta sampingan untuk setiap perkhidmatan. Pada dasarnya, ini adalah gabungan besar yang "boleh melakukan apa sahaja", dan idea utamanya ialah kebolehurusan maksimum, kebolehlanjutan, keselamatan dan ketelusan. Dengan itu, anda boleh memperhalusi penghalaan trafik, keizinan akses antara perkhidmatan, pengimbangan, pemantauan, keluaran kenari dan banyak lagi. Baca lebih lanjut mengenai Istio dalam siri artikel "'.
Duta Besar
Laman web:
Lesen: Apache 2.0
Satu lagi penyelesaian berdasarkan Utusan. Ia mempunyai versi percuma dan komersial. Ia diletakkan sebagai "asli sepenuhnya kepada Kubernetes", yang membawa kelebihan yang sepadan (integrasi ketat dengan kaedah dan entiti gugusan K8s).
Jadual Perbandingan
Jadi, kemuncak artikel adalah jadual besar ini:
Ia boleh diklik untuk paparan yang lebih dekat, dan juga tersedia dalam format .
Ringkasnya
Tujuan artikel ini adalah untuk memberikan pemahaman yang lebih lengkap (namun, sama sekali tidak menyeluruh!) tentang pilihan yang perlu dibuat dalam kes tertentu anda. Seperti biasa, setiap pengawal mempunyai kelebihan dan kekurangannya sendiriβ¦
Ingress klasik dari Kubernetes bagus untuk ketersediaan dan kebolehbuktiannya, ciri yang cukup kaya - dalam kes umum, ia sepatutnya "cukup untuk mata". Walau bagaimanapun, jika terdapat peningkatan keperluan untuk kestabilan, tahap ciri dan pembangunan, anda harus memberi perhatian kepada Ingress dengan NGINX Plus dan langganan berbayar. Kong mempunyai set pemalam terkaya (dan, oleh itu, peluang yang mereka sediakan), dan dalam versi berbayar terdapat lebih banyak daripada mereka. Ia mempunyai banyak peluang untuk berfungsi sebagai Gateway API, konfigurasi dinamik berdasarkan sumber CRD, serta perkhidmatan Kubernetes asas.
Dengan peningkatan keperluan untuk kaedah pengimbangan dan kebenaran, lihat Traefik dan HAProxy. Ini adalah projek Sumber Terbuka, terbukti selama ini, sangat stabil dan sedang membangun secara aktif. Kontur telah dikeluarkan selama beberapa tahun sekarang, tetapi ia masih kelihatan terlalu muda dan hanya mempunyai ciri asas yang ditambah di atas Utusan. Sekiranya terdapat keperluan untuk kehadiran / pembenaman WAF di hadapan aplikasi, anda harus memberi perhatian kepada Ingress yang sama dari Kubernetes atau HAProxy.
Dan yang paling kaya dari segi ciri adalah produk yang dibina di atas Utusan, terutamanya Istio. Ia nampaknya merupakan penyelesaian komprehensif yang "boleh melakukan apa sahaja", yang, bagaimanapun, juga bermakna ambang kemasukan yang jauh lebih tinggi untuk konfigurasi / pelancaran / pentadbiran daripada penyelesaian lain.
Kami telah memilih dan masih menggunakan Ingress daripada Kubernetes sebagai pengawal standard, yang meliputi 80-90% keperluan. Ia agak boleh dipercayai, mudah dikonfigurasikan dan dikembangkan. Secara umum, jika tiada keperluan khusus, ia harus sesuai dengan kebanyakan kluster / aplikasi. Daripada produk universal dan agak mudah yang sama, Traefik dan HAProxy boleh disyorkan.
PS
Baca juga di blog kami:
- "Kembali ke perkhidmatan mikro dengan Istio": , , ;
- «»;
- Β«'.
Sumber: www.habr.com