Ini adalah pembaruan untuk tolok ukur saya sebelumnya , yang sekarang berjalan di Kubernetes 1.14 dengan versi CNI saat ini untuk April 2019.
Pertama, saya ingin mengucapkan terima kasih kepada tim Cilium: mereka membantu saya memeriksa dan memperbaiki skrip pemantauan metrik.
Apa yang telah berubah sejak November 2018
Inilah yang telah berubah sejak saat itu (jika tertarik):
Flannel tetap menjadi antarmuka CNI tercepat dan termudah, tetapi masih tidak mendukung kebijakan dan enkripsi jaringan.
Romana tidak lagi didukung, jadi kami menghapusnya dari tolok ukur.
WeaveNet sekarang mendukung kebijakan jaringan untuk Ingress dan Egress! Tetapi produktivitas telah menurun.
Di Calico, Anda masih perlu mengkonfigurasi ukuran paket maksimum (MTU) secara manual untuk kinerja yang lebih baik. Calico menawarkan dua opsi instalasi CNI, sehingga Anda dapat melakukannya tanpa repositori ETCD terpisah:
- penyimpanan negara dalam API Kubernetes sebagai penyimpanan data (ukuran cluster <50 node);
- penyimpanan negara dalam API Kubernetes sebagai penyimpanan data dengan proxy Typha untuk mengurangi beban dari API K8S (ukuran cluster> 50 node).
Calico mengumumkan dukungan kebijakan tingkat aplikasi di atas Istio untuk keamanan tingkat aplikasi.
Cilium sekarang mendukung enkripsi! Cilium menyediakan enkripsi dengan terowongan IPSec dan menawarkan alternatif untuk jaringan WeaveNet terenkripsi. Tetapi WeaveNet lebih cepat dari Cilium dengan enkripsi diaktifkan.
Cilium sekarang lebih mudah digunakan - berkat operator ETCD bawaan.
Tim Cilium berusaha menjaga bobot CNI mereka, mengurangi konsumsi memori dan biaya CPU, tetapi para pesaing masih lebih ringan.
Konteks patokan
Benchmark dijalankan pada tiga server Supermicro yang tidak tervirtualisasi dengan saklar Supermicro 10 Gb. Server terhubung langsung ke sakelar melalui kabel DAC SFP + pasif dan dikonfigurasikan dalam VLAN yang sama dengan bingkai jumbo (MTU 9000).
Kubernetes 1.14.0 diinstal pada Ubuntu 18.04 LTS dengan Docker 18.09.2 (versi default Docker dalam rilis ini).
Untuk meningkatkan reproduktifitas, kami memutuskan untuk selalu mengonfigurasi master pada node pertama, menempatkan bagian server dari benchmark pada server kedua, dan bagian klien pada yang ketiga. Untuk ini, kami menggunakan NodeSelector dalam penerapan Kubernetes.
Hasil benchmark akan dijelaskan pada skala seperti ini:
Memilih CNI sebagai patokan
Ini adalah patokan khusus CNI dari daftar di bagian tentang membuat satu master cluster dengan kubeadm dalam dokumentasi Kubernetes resmi. Dari CNI 9 kami hanya mengambil 6: kami mengecualikan mereka yang sulit untuk menginstal dan / atau tidak bekerja tanpa konfigurasi dokumentasi (Romana, Contiv-VPP dan JuniperContrail / TungstenFabric).
Kami akan membandingkan CNI berikut:
- Calico v3.6
- Canal v3.6 (dasarnya Flannel 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 menginstal CNI, semakin baik kesan pertama kami. Semua CNI dari patokan sangat mudah dipasang (dengan satu atau dua tim).
Seperti yang kami katakan, server dan sakelar dikonfigurasi dengan frame jumbo diaktifkan (kami memasang MTU 9000). Kami akan senang jika CNI secara otomatis menentukan MTU berdasarkan pengaturan adaptor. Namun, hanya Cilium dan Flannel yang menangani ini. CNI lainnya memiliki permintaan pada GitHub untuk menambahkan deteksi MTU otomatis, tetapi kami akan mengonfigurasinya secara manual dengan mengubah ConfigMap untuk Calico, Canal dan Kube-router, atau dengan mengirimkan variabel lingkungan untuk WeaveNet.
Apa masalah dengan MTU yang salah? Diagram ini menunjukkan perbedaan antara WeaveNet dengan MTU default dan bingkai jumbo diaktifkan:
Bagaimana MTU memengaruhi bandwidth
Kami menemukan betapa pentingnya MTU untuk kinerja, dan sekarang mari kita lihat bagaimana CNI kami secara otomatis mendeteksinya:
CNI secara otomatis mendeteksi MTU
Grafik menunjukkan bahwa Anda perlu mengkonfigurasi MTU untuk Calico, Canal, Kube-router dan WeaveNet untuk kinerja yang optimal. Cilium dan Flannel sendiri dapat menentukan MTU dengan benar tanpa pengaturan apa pun.
Keamanan
Kami akan membandingkan keamanan CNI dalam dua aspek: kemampuan untuk mengenkripsi data yang ditransmisikan dan implementasi kebijakan jaringan Kubernetes (sesuai dengan tes nyata, bukan menurut dokumentasi).
Hanya dua CNI yang mengenkripsi data: Cilium dan WeaveNet. Enkripsi WeaveNet diaktifkan dengan menetapkan kata sandi enkripsi sebagai variabel lingkungan CNI. Dokumentasi WeaveNet menggambarkan ini rumit, tetapi semuanya dilakukan dengan sederhana. Enkripsi Cilium dikonfigurasi oleh perintah, dengan membuat rahasia Kubernetes, dan dengan memodifikasi daemonSet (sedikit lebih rumit daripada di WeaveNet, tetapi Cilium memiliki petunjuk langkah-demi-langkah).
Adapun implementasi kebijakan jaringan, Calico, Canal, Cilium dan WeaveNet berhasil di sini, di mana Anda dapat mengkonfigurasi aturan Ingress dan Egress. Untuk Kube-router, ada aturan hanya untuk Ingress, sementara Flannel tidak memiliki kebijakan jaringan sama sekali.
Berikut adalah hasil umumnya:
Hasil Benchmark untuk Fitur Keamanan
Performa
Benchmark ini menunjukkan throughput rata-rata untuk setidaknya tiga kali tes. Kami menguji kinerja TCP dan UDP (menggunakan iperf3), aplikasi nyata, misalnya, HTTP (dengan Nginx dan curl) atau FTP (dengan vsftpd dan curl) dan, akhirnya, pengoperasian aplikasi menggunakan enkripsi berdasarkan protokol SCP (menggunakan klien dan server OpenSSH).
Untuk semua pengujian, kami membuat tolok ukur bare-metal (jalur hijau) untuk membandingkan kinerja CNI dengan kinerja jaringan asli. Di sini kita menggunakan skala yang sama, tetapi warnanya:
- Kuning = sangat bagus
- Oranye = bagus
- Biru = begitu-begitu
- Merah = buruk
Kami tidak akan mengambil CNI yang dikonfigurasi secara tidak benar dan hanya menampilkan hasil untuk CNI dengan MTU yang benar. (Catatan: Cilium tidak mempertimbangkan MTU dengan benar jika enkripsi diaktifkan, jadi Anda harus mengurangi MTU menjadi 8900 secara manual di versi 1.4. Di versi berikutnya, 1.5, ini dilakukan secara otomatis.)
Inilah hasilnya:
Kinerja TCP
Semua CNI berkinerja baik dalam tolok ukur TCP. CNI terenkripsi jauh tertinggal karena enkripsi mahal.
Kinerja UDP
Di sini juga, semua CNI baik-baik saja. CNI terenkripsi menunjukkan hasil yang hampir sama. Cilium sedikit di belakang para pesaingnya, tetapi hanya 2,3% dari logam telanjang, sehingga hasilnya tidak buruk. Jangan lupa bahwa hanya Cilium dan Flannel yang menentukan MTU dengan benar, dan ini adalah hasilnya tanpa konfigurasi tambahan.
Bagaimana dengan aplikasi sungguhan? Seperti yang Anda lihat, untuk HTTP, kinerja keseluruhan sedikit lebih rendah daripada untuk TCP. Bahkan jika Anda menggunakan HTTP dengan TCP, dalam tolok ukur TCP kami mengkonfigurasi iperf3 untuk menghindari awal yang lambat, dan ini akan mempengaruhi tolok ukur HTTP. Semuanya dilakukan dengan baik di sini. Kube-router memiliki keuntungan yang jelas, dan WeaveNet menunjukkan dirinya bukan dari sisi terbaik: sekitar 20% lebih buruk daripada bare-metal. Cilium dan WeaveNet dengan enkripsi terlihat sangat sedih.
Dengan FTP, protokol berbasis TCP lainnya, hasilnya berbeda. Flannel dan Kube-router mengatasi, sementara Calico, Canal dan Cilium sedikit di belakang dan bekerja sekitar 10% lebih lambat daripada logam biasa. WeaveNet tidak mengikuti sebanyak 17%, tetapi WeaveNet dengan enkripsi adalah 40% di depan Cilium terenkripsi.
Dengan SCP Anda dapat segera melihat biaya enkripsi SSH kami. Hampir semua CNI melakukannya, dan WeaveNet tertinggal lagi. Cilium dan WeaveNet dengan enkripsi diharapkan menjadi yang terburuk dari semuanya karena enkripsi ganda (SSH + CNI).
Berikut ini adalah tabel ringkasan dengan hasilnya:
Konsumsi sumber daya
Sekarang mari kita bandingkan bagaimana CNI mengkonsumsi sumber daya di bawah beban berat (selama transmisi melalui TCP, 10 Gb / s). Dalam tes kinerja, kami membandingkan CNI dengan bare metal (garis hijau). Untuk mengkonsumsi sumber daya, kami akan menunjukkan Kubernetes murni (garis ungu) tanpa CNI dan melihat berapa banyak sumber daya tambahan yang dikonsumsi CNI.
Mari kita mulai dengan memori. Berikut adalah nilai rata-rata untuk memori host (tanpa buffer dan cache) dalam MB selama transfer.
Konsumsi memori
Flannel dan Kube-router menunjukkan hasil yang sangat baik - hanya 50 MB. Calico dan Canal masing-masing memiliki 70. WeaveNet jelas mengkonsumsi lebih dari yang lain - 130 MB, sementara Cilium menggunakan sebanyak 400.
Sekarang mari kita periksa penggunaan CPU. Yang perlu diperhatikan : dalam diagram, bukan persentase, tetapi per mille, yaitu, 38 ppm untuk “besi kosong” - ini adalah 3,8%. Inilah hasilnya:
Konsumsi CPU
Calico, Canal, Flannel dan Kube-router menggunakan CPU dengan sangat efisien - hanya 2% lebih banyak dari Kubernet tanpa CNI. WeaveNet jauh di belakang dengan tambahan 5%, diikuti oleh Cilium - 7%.
Berikut ini ringkasan konsumsi sumber daya:
Ringkasan
Tabel dengan semua hasil:
Hasil patokan umum
Kesimpulan
Pada bagian terakhir, saya akan mengungkapkan pendapat subjektif saya tentang hasilnya. Ingatlah bahwa tolok ukur ini hanya menguji throughput satu koneksi pada sebuah cluster yang sangat kecil (3 node). Itu tidak berlaku untuk kelompok besar (<50 node) atau koneksi paralel.
Saya sarankan menggunakan CNI berikut tergantung pada skenario:
- Anda memiliki node dengan sejumlah kecil sumber daya di cluster Anda (beberapa GB RAM, beberapa core) dan Anda tidak memerlukan fitur keamanan - pilih Flannel . Ini adalah salah satu CNI paling ekonomis. Dan itu kompatibel dengan berbagai macam arsitektur (amd64, arm, arm64, dll.). Selain itu, ini adalah salah satu dari dua (yang kedua adalah Cilium) CNI, yang dapat secara otomatis menentukan MTU, sehingga Anda tidak perlu mengkonfigurasi apa pun. Kube-router juga cocok, tetapi tidak terlalu standar dan Anda harus mengkonfigurasi MTU secara manual.
- Jika Anda perlu mengenkripsi jaringan untuk keamanan, ambil WeaveNet . Jangan lupa untuk menentukan ukuran MTU, jika menggunakan bingkai jumbo, dan aktifkan enkripsi dengan menentukan kata sandi melalui variabel lingkungan. Tetapi lebih baik melupakan kinerja - ini adalah biaya enkripsi.
- Untuk penggunaan normal, saya sarankan Calico . CNI ini banyak digunakan di berbagai alat penyebaran Kubernetes (Kops, Kubespray, Rancher, dll.). Seperti halnya WeaveNet, ingatlah untuk mengkonfigurasi MTU di ConfigMap jika Anda menggunakan bingkai jumbo. Ini adalah alat multi-fungsi, efektif dalam hal konsumsi sumber daya, produktivitas, dan keamanan.
Dan akhirnya, saya menyarankan Anda untuk mengikuti pengembangan Cilium . CNI ini memiliki tim yang sangat aktif yang bekerja keras untuk produknya (fitur, menghemat sumber daya, produktivitas, keamanan, distribusi klaster ...), dan mereka memiliki rencana yang sangat menarik.
Diagram Visual untuk Pilihan CNI