Ini pembaruan saya , yang kini berjalan di Kubernetes 1.14 dengan versi CNI terbaru per April 2019.
Pertama-tama, saya ingin mengucapkan terima kasih kepada tim Cilium: mereka membantu saya memeriksa dan memperbaiki skrip pemantauan metrik.
Apa yang berubah sejak November 2018
Inilah yang berubah sejak saat itu (jika Anda tertarik):
Flanel tetap menjadi antarmuka CNI tercepat dan paling sederhana, namun masih belum mendukung kebijakan jaringan dan enkripsi.
Romana tidak lagi didukung, jadi kami menghapusnya dari benchmark.
WeaveNet sekarang mendukung kebijakan jaringan untuk Ingress dan Egress! Namun produktivitasnya menurun.
Di Calico, Anda masih perlu mengkonfigurasi ukuran paket maksimum (MTU) secara manual untuk performa terbaik. Calico menawarkan dua opsi untuk menginstal CNI, sehingga Anda dapat melakukannya tanpa repositori ETCD terpisah:
- menyimpan status di API Kubernetes sebagai penyimpan data (ukuran cluster <50 node);
- menyimpan status di API Kubernetes sebagai penyimpanan data dengan proksi Typha untuk meringankan beban pada API K8S (ukuran cluster > 50 node).
Calico mengumumkan dukungannya di atas Istio untuk keamanan tingkat aplikasi.
Cilium sekarang mendukung enkripsi! Cilium menyediakan enkripsi dengan terowongan IPSec dan menawarkan alternatif untuk jaringan WeaveNet terenkripsi. Tapi WeaveNet lebih cepat dari Cilium dengan enkripsi diaktifkan.
Cilium sekarang lebih mudah untuk diterapkan berkat operator ETCD bawaan.
Tim Cilium telah mencoba mengurangi bobot CNI-nya dengan mengurangi konsumsi memori dan biaya CPU, namun pesaingnya masih lebih ringan.
Konteks tolok ukur
Benchmark dijalankan pada tiga server Supermicro non-virtualisasi dengan switch Supermicro 10 Gb. Server terhubung langsung ke switch melalui kabel DAC SFP+ pasif dan dikonfigurasi pada VLAN yang sama dengan frame jumbo (MTU 9000).
Kubernetes 1.14.0 diinstal di Ubuntu 18.04 LTS dengan Docker 18.09.2 (versi Docker default dalam rilis ini).
Untuk meningkatkan reproduktifitas, kami memutuskan untuk selalu mengkonfigurasi master pada node pertama, menempatkan bagian server dari benchmark pada server kedua, dan bagian klien pada node ketiga. Untuk melakukan ini, kami menggunakan NodeSelector dalam penerapan Kubernetes.
Hasil benchmark akan kami uraikan dalam skala berikut:
Memilih CNI untuk benchmark
Ini hanya patokan untuk CNI dari daftar di bagian tersebut Lihat dokumentasi resmi Kubernetes. Dari 9 CNI, kami hanya akan mengambil 6: kami akan mengecualikan CNI yang sulit dipasang dan/atau tidak berfungsi tanpa konfigurasi sesuai dengan dokumentasi (Romana, Contiv-VPP, dan JuniperContrail/TungstenFabric).
Kami akan membandingkan CNI berikut:
- Calico v3.6
- Canal v3.6 (pada dasarnya Flanel untuk jaringan + Calico sebagai firewall)
- Cilium 1.4.2
- Flanel 0.11.0
- Kube-router 0.2.5
- WeaveNet 2.5.1
Instalasi
Semakin mudah CNI dipasang, maka kesan pertama kita akan semakin baik. Semua CNI dari benchmark sangat mudah dipasang (dengan satu atau dua perintah).
Seperti yang kami katakan, server dan switch dikonfigurasi dengan frame jumbo yang diaktifkan (kami mengatur MTU ke 9000). Kami akan senang jika CNI secara otomatis menentukan MTU berdasarkan konfigurasi adaptor. Namun, hanya Cilium dan Flanel yang berhasil melakukannya. CNI lainnya memiliki permintaan di GitHub untuk menambahkan penemuan MTU otomatis, tetapi kami akan mengonfigurasinya secara manual dengan mengubah ConfigMap untuk Calico, Canal, dan router Kube, atau meneruskan variabel lingkungan untuk WeaveNet.
Apa masalah dengan MTU yang salah? Diagram ini menunjukkan perbedaan antara WeaveNet dengan MTU default dan frame jumbo yang diaktifkan:
Bagaimana MTU mempengaruhi throughput?
Kita telah melihat betapa pentingnya MTU bagi kinerja, sekarang mari kita lihat bagaimana CNI kita menentukannya secara otomatis:
CNI secara otomatis mendeteksi MTU
Grafik menunjukkan bahwa Anda perlu mengkonfigurasi MTU untuk Calico, Canal, Kube-router dan WeaveNet untuk kinerja optimal. Cilium dan Flanel dapat menentukan MTU sendiri dengan benar tanpa pengaturan apa pun.
keamanan
Kami akan membandingkan keamanan CNI dalam dua aspek: kemampuan mengenkripsi data yang dikirimkan dan penerapan kebijakan jaringan Kubernetes (berdasarkan pengujian nyata, bukan dokumentasi).
Hanya dua CNI yang mengenkripsi data: Cilium dan WeaveNet. Enkripsi TenunNet diaktifkan dengan mengatur kata sandi enkripsi sebagai variabel lingkungan CNI. DI DALAM WeaveNet menjelaskannya dengan cara yang rumit, tetapi semuanya dilakukan dengan sederhana. Enkripsi silia dikonfigurasi dengan perintah, dengan membuat rahasia Kubernetes, dan melalui modifikasi daemonSet (sedikit lebih rumit daripada di WeaveNet, tetapi Cilium memiliki langkah demi langkah ).
Sedangkan untuk implementasi kebijakan jaringan, mereka berhasil Calico, Kanal, Cilium dan WeaveNet, tempat Anda dapat mengonfigurasi aturan Ingress dan Egress. Untuk Kube-router ada aturan hanya untuk Ingress, dan Flanel Tidak ada kebijakan jaringan sama sekali.
Berikut hasil keseluruhannya:
Hasil Tolok Ukur Kinerja Keselamatan
Performa
Tolok ukur ini menunjukkan throughput rata-rata selama setidaknya tiga kali proses pada setiap pengujian. Kami menguji kinerja TCP dan UDP (menggunakan iperf3), aplikasi nyata seperti HTTP (dengan Nginx dan curl) atau FTP (dengan vsftpd dan curl) dan terakhir kinerja aplikasi menggunakan enkripsi berbasis SCP (menggunakan OpenSSH klien dan server).
Untuk semua pengujian, kami melakukan benchmark bare metal (garis hijau) untuk membandingkan kinerja CNI dengan kinerja jaringan asli. Di sini kita menggunakan skala yang sama, tetapi dalam warna:
- Kuning = sangat bagus
- Oranye = bagus
- Biru = biasa saja
- Merah = buruk
Kami tidak akan mengambil CNI yang dikonfigurasi secara salah dan hanya akan menampilkan hasil untuk CNI dengan MTU yang benar. (Catatan: Cilium tidak menghitung MTU dengan benar jika Anda mengaktifkan enkripsi, jadi Anda harus mengurangi MTU secara manual menjadi 8900 di versi 1.4. Versi berikutnya, 1.5, melakukannya secara otomatis.)
Berikut adalah hasilnya:
Kinerja TCP
Semua CNI berkinerja baik dalam benchmark TCP. CNI dengan enkripsi tertinggal jauh karena enkripsi mahal.
kinerja UDP
Di sini juga, semua CNI berjalan dengan baik. CNI dengan enkripsi menunjukkan hasil yang hampir sama. Cilium sedikit tertinggal dari kompetisi, tapi hanya 2,3% dari bare metal, jadi ini bukan hasil yang buruk. Jangan lupa bahwa hanya Cilium dan Flannel yang menentukan MTU dengan benar, dan ini adalah hasilnya tanpa konfigurasi tambahan apa pun.
Bagaimana dengan aplikasi nyata? Seperti yang Anda lihat, kinerja keseluruhan untuk HTTP sedikit lebih rendah daripada TCP. Meskipun Anda menggunakan HTTP dengan TCP, kami mengonfigurasi iperf3 di benchmark TCP untuk menghindari permulaan yang lambat yang akan memengaruhi benchmark HTTP. Semua orang melakukan pekerjaan dengan baik di sini. Kube-router memiliki keunggulan yang jelas, tetapi kinerja WeaveNet tidak baik: sekitar 20% lebih buruk daripada bare metal. Cilium dan WeaveNet dengan enkripsi terlihat sangat menyedihkan.
Dengan FTP, protokol berbasis TCP lainnya, hasilnya bervariasi. Flanel dan Kube-router melakukan tugasnya, tetapi Calico, Canal, dan Cilium sedikit tertinggal dan sekitar 10% lebih lambat dibandingkan bare metal. WeaveNet tertinggal sebanyak 17%, namun WeaveNet terenkripsi 40% lebih unggul dari Cilium terenkripsi.
Dengan SCP kita bisa langsung melihat berapa biaya enkripsi SSH yang kita keluarkan. Hampir semua CNI berjalan dengan baik, namun WeaveNet kembali tertinggal. Cilium dan WeaveNet dengan enkripsi diperkirakan menjadi yang terburuk karena enkripsi ganda (SSH + CNI).
Berikut tabel ringkasan beserta hasilnya:
Konsumsi sumber daya
Sekarang mari kita bandingkan bagaimana CNI menggunakan sumber daya pada beban berat (selama transfer TCP, 10 Gbps). Dalam uji kinerja kami membandingkan CNI dengan bare metal (garis hijau). Untuk konsumsi sumber daya, mari tunjukkan Kubernetes murni (garis ungu) tanpa CNI dan lihat berapa banyak sumber daya tambahan yang dikonsumsi CNI.
Mari kita mulai dengan ingatan. Berikut adalah nilai rata-rata RAM node (tidak termasuk buffer dan cache) dalam MB selama transfer.
Konsumsi memori
Flanel dan Kube-router menunjukkan hasil yang sangat baik - hanya 50 MB. Calico dan Canal masing-masing memiliki 70. WeaveNet jelas mengkonsumsi lebih banyak daripada yang lain - 130 MB, dan Cilium menggunakan sebanyak 400 MB.
Sekarang mari kita periksa konsumsi waktu CPU. Penting: diagram tidak menunjukkan persentase, tetapi ppm, yaitu 38 ppm untuk “besi telanjang” adalah 3,8%. Berikut hasilnya:
Konsumsi CPU
Calico, Canal, Flannel, dan Kube-router sangat hemat CPU - hanya 2% lebih banyak dibandingkan Kubernetes tanpa CNI. WeaveNet tertinggal jauh dengan tambahan 5%, diikuti oleh Cilium sebesar 7%.
Berikut ringkasan konsumsi sumber daya:
Hasil
Tabel dengan semua hasil:
Hasil benchmark umum
Kesimpulan
Pada bagian terakhir saya akan mengungkapkan pendapat subjektif saya tentang hasilnya. Ingatlah bahwa benchmark ini hanya menguji throughput dari satu koneksi pada cluster yang sangat kecil (3 node). Ini tidak berlaku untuk cluster besar (<50 node) atau koneksi paralel.
Saya merekomendasikan penggunaan CNI berikut tergantung pada skenarionya:
- Apakah Anda memilikinya di cluster Anda node dengan sedikit sumber daya (beberapa GB RAM, beberapa inti) dan Anda tidak memerlukan fitur keamanan - pilihlah Flanel. Ini adalah salah satu CNI yang paling hemat biaya. Dan itu kompatibel dengan berbagai macam arsitektur (amd64, arm, arm64, dll.). Selain itu, ini adalah salah satu dari dua (yang lainnya adalah Cilium) CNI yang dapat menentukan MTU secara otomatis, jadi Anda tidak perlu mengonfigurasi apa pun. Kube-router juga cocok, tetapi tidak standar dan Anda perlu mengkonfigurasi MTU secara manual.
- Jika diperlukan mengenkripsi jaringan untuk keamanan, ambil TenunNet. Jangan lupa untuk menentukan ukuran MTU jika Anda menggunakan frame jumbo, dan aktifkan enkripsi dengan menentukan kata sandi melalui variabel lingkungan. Namun lebih baik melupakan kinerja - itulah biaya enkripsi.
- Untuk penggunaan normal Советую Belacu. CNI ini banyak digunakan di berbagai alat penerapan Kubernetes (Kops, Kubespray, Rancher, dll). Seperti halnya WeaveNet, pastikan untuk mengonfigurasi MTU di ConfigMap jika menggunakan frame jumbo. Ini adalah alat multifungsi yang efisien dalam hal konsumsi sumber daya, kinerja, dan keamanan.
Dan terakhir, saya menyarankan Anda untuk mengikuti perkembangannya silia. CNI ini memiliki tim yang sangat aktif yang banyak mengerjakan produknya (fitur, penghematan sumber daya, kinerja, keamanan, pengelompokan...) dan mereka memiliki rencana yang sangat menarik.
Diagram visual untuk pemilihan CNI
Sumber: www.habr.com