Keputusan Penanda Aras Pemalam Rangkaian Kubernetes (CNI) melebihi 10 Gbps Rangkaian (Dikemas kini: April 2019)

Ini kemas kini saya penanda aras sebelumnya, yang kini berjalan pada Kubernetes 1.14 dengan versi CNI terkini pada April 2019.

Pertama sekali, saya ingin mengucapkan terima kasih kepada pasukan Cilium: mereka membantu saya menyemak dan membetulkan skrip pemantauan metrik.

Apa yang telah berubah sejak November 2018

Berikut ialah perkara yang berubah sejak itu (jika anda berminat):

Flanel kekal sebagai antara muka CNI terpantas dan paling mudah, tetapi masih tidak menyokong dasar rangkaian dan penyulitan.

Romana tidak lagi disokong, jadi kami telah mengalih keluarnya daripada penanda aras.

WeaveNet kini menyokong dasar rangkaian untuk Ingress dan Egress! Tetapi produktiviti telah menurun.

Dalam Calico, anda masih perlu mengkonfigurasi saiz paket maksimum (MTU) secara manual untuk prestasi terbaik. Calico menawarkan dua pilihan untuk memasang CNI, jadi anda boleh melakukannya tanpa repositori ETCD yang berasingan:

• menyimpan keadaan dalam API Kubernetes sebagai stor data (saiz kluster < 50 nod);
• menyimpan keadaan dalam API Kubernetes sebagai stor data dengan proksi Typha untuk meringankan beban pada API K8S (saiz kluster > 50 nod).

Calico mengumumkan sokongan dasar peringkat aplikasi di atas Istio untuk keselamatan peringkat aplikasi.

Cilium kini menyokong penyulitan! Cilium menyediakan penyulitan dengan terowong IPSec dan menawarkan alternatif kepada rangkaian WeaveNet yang disulitkan. Tetapi WeaveNet lebih pantas daripada Cilium dengan penyulitan didayakan.

Cilium kini lebih mudah untuk digunakan terima kasih kepada pengendali ETCD terbina dalam.

Pasukan Cilium telah cuba mengurangkan sedikit berat daripada CNInya dengan mengurangkan penggunaan memori dan kos CPU, tetapi pesaingnya masih lebih ringan.

Konteks penanda aras

Penanda aras dijalankan pada tiga pelayan Supermicro tidak maya dengan suis Supermicro 10 Gb. Pelayan disambungkan terus ke suis melalui kabel DAC SFP+ pasif dan dikonfigurasikan pada VLAN yang sama dengan bingkai jumbo (MTU 9000).

Kubernetes 1.14.0 dipasang pada Ubuntu 18.04 LTS dengan Docker 18.09.2 (versi Docker lalai dalam keluaran ini).

Untuk meningkatkan kebolehulangan, kami memutuskan untuk sentiasa mengkonfigurasi induk pada nod pertama, meletakkan bahagian pelayan penanda aras pada pelayan kedua, dan bahagian klien pada yang ketiga. Untuk melakukan ini, kami menggunakan NodeSelector dalam penyebaran Kubernetes.

Kami akan menerangkan hasil penanda aras pada skala berikut:

Memilih CNI untuk penanda aras

Ini adalah penanda aras hanya untuk CNI daripada senarai dalam bahagian tentang mencipta satu kluster induk dengan kubeadm Lihat dokumentasi rasmi Kubernetes. Daripada 9 CNI, kami akan mengambil hanya 6: kami akan mengecualikan yang sukar dipasang dan/atau tidak berfungsi tanpa konfigurasi mengikut dokumentasi (Romana, Contiv-VPP dan JuniperContrail/TungstenFabric).

Kami akan membandingkan CNI berikut:

• Calico v3.6
• Canal v3.6 (pada asasnya Flanel untuk rangkaian + Calico sebagai tembok api)
• Cilium 1.4.2
• Flanel 0.11.0
• Kube-router 0.2.5
• WeaveNet 2.5.1

Pemasangan

Lebih mudah CNI dipasang, lebih baik kesan pertama kita. Semua CNI daripada penanda aras sangat mudah untuk dipasang (dengan satu atau dua arahan).

Seperti yang kami katakan, pelayan dan suis dikonfigurasikan dengan bingkai jumbo didayakan (kami menetapkan MTU kepada 9000). Kami akan gembira jika CNI menentukan MTU secara automatik berdasarkan konfigurasi penyesuai. Walau bagaimanapun, hanya Cilium dan Flanel yang berjaya. Selebihnya CNI mempunyai permintaan pada GitHub untuk menambah penemuan MTU automatik, tetapi kami akan mengkonfigurasinya secara manual dengan menukar ConfigMap untuk Calico, Canal dan Kube-router, atau menghantar pembolehubah persekitaran untuk WeaveNet.

Apakah masalah dengan MTU yang salah? Rajah ini menunjukkan perbezaan antara WeaveNet dengan MTU lalai dan bingkai jumbo didayakan:

Bagaimanakah MTU mempengaruhi daya tampung?

Kami telah melihat betapa pentingnya MTU untuk prestasi, sekarang mari lihat cara CNI kami menentukannya secara automatik:

CNI secara automatik mengesan MTU

Graf menunjukkan bahawa anda perlu mengkonfigurasi MTU untuk Calico, Canal, Kube-router dan WeaveNet untuk prestasi optimum. Cilium dan Flanel dapat menentukan sendiri MTU dengan betul tanpa sebarang tetapan.

keselamatan

Kami akan membandingkan keselamatan CNI dalam dua aspek: keupayaan untuk menyulitkan data yang dihantar dan pelaksanaan dasar rangkaian Kubernetes (berdasarkan ujian sebenar, bukan dokumentasi).

Hanya dua CNI menyulitkan data: Cilium dan WeaveNet. Penyulitan WeaveNet didayakan dengan menetapkan kata laluan penyulitan sebagai pembolehubah persekitaran CNI. DALAM dokumentasi WeaveNet menerangkannya dengan cara yang rumit, tetapi semuanya dilakukan dengan mudah. Penyulitan cilium dikonfigurasikan dengan arahan, dengan mencipta rahsia Kubernetes, dan melalui pengubahsuaian daemonSet (sedikit lebih rumit daripada di WeaveNet, tetapi Cilium mempunyai langkah demi langkah Directions).

Bagi pelaksanaan dasar rangkaian, mereka telah berjaya Calico, Canal, Cilium dan WeaveNet, di mana anda boleh mengkonfigurasi peraturan Ingress dan Egress. Untuk Kube-router terdapat peraturan hanya untuk Ingress, dan Flanel Tiada dasar rangkaian sama sekali.

Berikut adalah keputusan keseluruhan:

Keputusan Penanda Aras Prestasi Keselamatan

Produktiviti

Penanda aras ini menunjukkan purata hasil sepanjang sekurang-kurangnya tiga larian bagi setiap ujian. Kami menguji prestasi TCP dan UDP (menggunakan iperf3), aplikasi sebenar seperti HTTP (dengan Nginx dan curl) atau FTP (dengan vsftpd dan curl) dan akhirnya prestasi aplikasi menggunakan penyulitan berasaskan SCP (menggunakan klien dan pelayan OpenSSH).

Untuk semua ujian, kami melakukan penanda aras logam kosong (garisan hijau) untuk membandingkan prestasi CNI dengan prestasi rangkaian asli. Di sini kami menggunakan skala yang sama, tetapi dalam warna:

• Kuning = sangat baik
• Oren = baik
• Biru = begitu-begitu
• Merah = buruk

Kami tidak akan mengambil CNI yang dikonfigurasikan dengan salah dan hanya akan menunjukkan keputusan untuk CNI dengan MTU yang betul. (Nota: Cilium tidak mengira MTU dengan betul jika anda mendayakan penyulitan, jadi anda perlu mengurangkan MTU secara manual kepada 8900 dalam versi 1.4. Versi seterusnya, 1.5, melakukan ini secara automatik.)

Berikut adalah keputusannya:

Prestasi TCP

Semua CNI menunjukkan prestasi yang baik dalam penanda aras TCP. CNI dengan penyulitan jauh ketinggalan kerana penyulitan mahal.

Prestasi UDP

Di sini juga, semua CNI berjalan lancar. CNI dengan penyulitan menunjukkan hasil yang hampir sama. Cilium agak ketinggalan dalam persaingan, tetapi ia hanya 2,3% daripada logam kosong, jadi ia bukan keputusan yang buruk. Jangan lupa bahawa hanya Cilium dan Flanel yang menentukan MTU dengan betul sendiri, dan ini adalah keputusannya tanpa sebarang konfigurasi tambahan.

Bagaimana dengan aplikasi sebenar? Seperti yang anda lihat, prestasi keseluruhan untuk HTTP adalah lebih rendah sedikit daripada TCP. Walaupun anda menggunakan HTTP dengan TCP, kami mengkonfigurasi iperf3 dalam penanda aras TCP untuk mengelakkan permulaan perlahan yang akan menjejaskan penanda aras HTTP. Semua orang melakukan kerja yang baik di sini. Kube-router mempunyai kelebihan yang jelas, tetapi WeaveNet tidak menunjukkan prestasi yang baik: kira-kira 20% lebih teruk daripada logam kosong. Cilium dan WeaveNet dengan penyulitan kelihatan sangat menyedihkan.

Dengan FTP, satu lagi protokol berasaskan TCP, keputusan berbeza-beza. Flanel dan Kube-router melakukan tugas itu, tetapi Calico, Canal dan Cilium agak ketinggalan dan kira-kira 10% lebih perlahan daripada logam kosong. WeaveNet ketinggalan sebanyak 17%, tetapi WeaveNet yang disulitkan adalah 40% di hadapan Cilium yang disulitkan.

Dengan SCP kita boleh melihat dengan serta-merta berapa banyak kos penyulitan SSH kita. Hampir semua CNI berfungsi dengan baik, tetapi WeaveNet ketinggalan sekali lagi. Cilium dan WeaveNet dengan penyulitan dijangka paling teruk disebabkan penyulitan berganda (SSH + CNI).

Berikut ialah jadual ringkasan dengan keputusan:

Penggunaan sumber

Sekarang mari kita bandingkan cara CNI menggunakan sumber di bawah beban berat (semasa pemindahan TCP, 10 Gbps). Dalam ujian prestasi kami membandingkan CNI dengan logam kosong (garisan hijau). Untuk penggunaan sumber, mari tunjukkan Kubernetes tulen (garis ungu) tanpa CNI dan lihat berapa banyak sumber tambahan yang digunakan CNI.

Mari kita mulakan dengan ingatan. Berikut ialah nilai purata untuk RAM nod (tidak termasuk penimbal dan cache) dalam MB semasa pemindahan.

Penggunaan ingatan

Flanel dan Kube-router menunjukkan hasil yang sangat baik - hanya 50 MB. Calico dan Canal masing-masing mempunyai 70. WeaveNet jelas menggunakan lebih banyak daripada yang lain - 130 MB, dan Cilium menggunakan sebanyak 400.
Sekarang mari kita semak penggunaan masa CPU. Diperhatikan: rajah menunjukkan bukan peratusan, tetapi ppm, iaitu, 38 ppm untuk "besi kosong" ialah 3,8%. Berikut adalah keputusannya:

penggunaan CPU

Calico, Canal, Flanel dan Kube-router sangat cekap CPU - hanya 2% lebih daripada Kubernetes tanpa CNI. WeaveNet jauh ketinggalan dengan tambahan 5%, diikuti oleh Cilium pada 7%.

Berikut ialah ringkasan penggunaan sumber:

Keputusan

Jadual dengan semua keputusan:

Keputusan penanda aras umum

Kesimpulan

Pada bahagian terakhir saya akan menyatakan pendapat subjektif saya tentang hasilnya. Ingat bahawa penanda aras ini hanya menguji daya pemprosesan satu sambungan pada kelompok yang sangat kecil (3 nod). Ia tidak terpakai kepada kluster besar (<50 nod) atau sambungan selari.

Saya mengesyorkan menggunakan CNI berikut bergantung pada senario:

• Adakah anda ada dalam kluster anda nod dengan sedikit sumber (beberapa GB RAM, beberapa teras) dan anda tidak memerlukan ciri keselamatan - pilih Flanel. Ini adalah salah satu CNI yang paling kos efektif. Dan ia serasi dengan pelbagai jenis seni bina (amd64, lengan, arm64, dll.). Di samping itu, ini adalah satu daripada dua (yang lain ialah Cilium) CNI yang boleh menentukan MTU secara automatik, jadi anda tidak perlu mengkonfigurasi apa-apa. Kube-router juga sesuai, tetapi ia tidak seperti standard dan anda perlu mengkonfigurasi MTU secara manual.
• Sekiranya perlu menyulitkan rangkaian untuk keselamatan, ambil WeaveNet. Jangan lupa untuk menentukan saiz MTU jika anda menggunakan bingkai jumbo, dan dayakan penyulitan dengan menentukan kata laluan melalui pembolehubah persekitaran. Tetapi lebih baik melupakan prestasi - itulah kos penyulitan.
• Untuk penggunaan biasa menasihati Calico. CNI ini digunakan secara meluas dalam pelbagai alatan penggunaan Kubernetes (Kops, Kubespray, Rancher, dll.). Seperti WeaveNet, pastikan anda mengkonfigurasi MTU dalam ConfigMap jika menggunakan bingkai jumbo. Ia adalah alat pelbagai fungsi yang cekap dari segi penggunaan sumber, prestasi dan keselamatan.

Dan akhirnya, saya menasihati anda untuk mengikuti perkembangan cilium. CNI ini mempunyai pasukan yang sangat aktif yang banyak bekerja pada produk mereka (ciri, penjimatan sumber, prestasi, keselamatan, pengelompokan...) dan mereka mempunyai rancangan yang sangat menarik.

Gambar rajah visual untuk pemilihan CNI

Sumber: www.habr.com