TL; DR: Semua CNI berfungsi sebagaimana mestinya, kecuali Kube-Router dan Kube-OVN, Calico, dengan pengecualian deteksi MTU otomatis, adalah yang terbaik.
Pembaruan artikel dari cek saya yang lalu ( ΠΈ ), pada saat pengujian saya menggunakan Kubernetes 1.19 di Ubuntu 18.04 dengan CNI yang diperbarui pada Agustus 2020.
Sebelum kita mendalami metrik...
Apa yang baru sejak April 2019?
- Dapat menguji pada klaster Anda sendiri: Anda dapat menjalankan pengujian pada klaster Anda sendiri menggunakan alat kami Tolok Ukur Jaringan Kubernetes:
- Anggota baru telah muncul
- dari VMware Tanzu
- dari alauda.io
- Skenario Baru: Pemeriksaan saat ini menjalankan pengujian kinerja jaringan "Pod-to-Pod", dan skrip "Pod-to-Service" baru telah ditambahkan yang menjalankan pengujian mendekati kondisi dunia nyata. Dalam praktiknya, Pod Anda dengan API bekerja dengan basis sebagai layanan, dan bukan melalui alamat ip Pod (tentu saja kami memeriksa TCP dan UDP untuk kedua skenario).
- Konsumsi sumber daya: setiap pengujian kini memiliki perbandingan sumber dayanya sendiri
- Menghapus Pengujian Aplikasi: Kami tidak lagi melakukan pengujian HTTP, FTP, dan SCP karena kolaborasi kami yang bermanfaat dengan komunitas dan pengelola CNI telah menemukan kesenjangan antara hasil iperf melalui TCP dan hasil curl karena penundaan dalam startup CNI (beberapa detik pertama Pod startup, yang tidak khas dalam kondisi nyata).
- Sumber terbuka: semua sumber pengujian (skrip, pengaturan yml, dan data "mentah" asli) tersedia
Protokol Uji Referensi
Protokolnya dijelaskan secara rinci Harap dicatat bahwa artikel ini tentang Ubuntu 18.04 dengan kernel default.
Memilih CNI untuk Penilaian
Pengujian ini bertujuan untuk membandingkan CNI yang dikonfigurasi dengan satu file yaml (oleh karena itu, semua yang diinstal oleh skrip, seperti VPP dan lainnya, tidak termasuk).
CNI pilihan kami untuk perbandingan:
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (Jaringan flanel + Kebijakan Jaringan Calico)
- Cilium 1.8.2
- Flanel 0.12.0
- Kube-router terbaru (2020β08β25)
- WeaveNet 2.7.0
Mengonfigurasi MTU untuk CNI
Pertama-tama, kami memeriksa dampak deteksi MTU otomatis pada kinerja TCP:
Dampak MTU pada Kinerja TCP
Kesenjangan yang lebih besar ditemukan ketika menggunakan UDP:
Dampak MTU terhadap Kinerja UDP
Mengingat dampak kinerja BESAR yang terungkap dalam pengujian, kami ingin mengirimkan surat harapan kepada semua pengelola CNI: harap tambahkan deteksi MTU otomatis ke CNI. Anda akan menyelamatkan anak kucing, unicorn, dan bahkan yang paling lucu: Devop kecil.
Namun, jika Anda perlu menggunakan CNI tanpa dukungan deteksi MTU otomatis, Anda dapat mengonfigurasinya secara manual untuk mendapatkan performa. Harap diperhatikan bahwa ini berlaku untuk Calico, Canal, dan WeaveNet.
Permintaan kecil saya kepada CNI pendamping...
Pengujian CNI: Data Mentah
Pada bagian ini, kita akan membandingkan CNI dengan MTU yang benar (ditentukan secara otomatis atau diatur secara manual). Tujuan utamanya di sini adalah menampilkan data mentah dalam bentuk grafik.
Legenda warna:
- abu-abu - sampel (yaitu besi telanjang)
- hijau - bandwidth di atas 9500 Mbps
- kuning - bandwidth di atas 9000 Mbps
- oranye - bandwidth di atas 8000 Mbps
- merah - bandwidth di bawah 8000 Mbps
- biru - netral (tidak terkait dengan bandwidth)
Konsumsi sumber daya tanpa beban
Pertama-tama, periksa konsumsi sumber daya saat cluster sedang βtidurβ.
Konsumsi sumber daya tanpa beban
Pod-ke-Pod
Skenario ini mengasumsikan bahwa Pod klien terhubung langsung ke Pod server menggunakan alamat IP-nya.
Skenario Pod-ke-Pod
TCP
Hasil TCP Pod-to-Pod dan konsumsi sumber daya yang sesuai:
UDP
Hasil UDP Pod-to-Pod dan konsumsi sumber daya terkait:
Pod-ke-Layanan
Bagian ini relevan untuk kasus penggunaan nyata, Pod klien terhubung ke Pod server melalui layanan ClusterIP.
Skrip Pod-ke-Layanan
TCP
Hasil TCP Pod-to-Service dan konsumsi sumber daya terkait:
UDP
Hasil UDP Pod-to-Service dan konsumsi sumber daya terkait:
Dukungan kebijakan jaringan
Di antara semua hal di atas, satu-satunya yang tidak mendukung politik adalah Flanel. Semua yang lain menerapkan kebijakan jaringan dengan benar, termasuk masuk dan keluar. Kerja bagus!
Enkripsi CNI
Di antara CNI yang diperiksa ada yang dapat mengenkripsi pertukaran jaringan antar Pod:
- Antrea menggunakan IPsec
- Calico menggunakan wireguard
- Cilium menggunakan IPsec
- WeaveNet menggunakan IPSec
Bandwidth
Karena CNI yang tersisa lebih sedikit, mari kita gabungkan semua skenario ke dalam satu grafik:
Konsumsi sumber daya
Pada bagian ini, kita akan mengevaluasi sumber daya yang digunakan saat memproses komunikasi Pod-ke-Pod dalam TCP dan UDP. Tidak ada gunanya menggambar grafik Pod-to-Service karena tidak memberikan informasi tambahan.
Menyatukan semuanya
Mari kita coba ulangi semua grafik, kami memperkenalkan sedikit subjektivitas di sini, mengganti nilai sebenarnya dengan kata "sangat cepat", "rendah", dll.
Kesimpulan dan kesimpulan saya
Ini sedikit subyektif, karena saya menyampaikan interpretasi saya sendiri terhadap hasilnya.
Saya senang CNI baru muncul, Antrea bekerja dengan baik, banyak fungsi diterapkan bahkan di versi awal: deteksi MTU otomatis, enkripsi, dan instalasi mudah.
Jika kita bandingkan performanya, semua CNI bekerja dengan baik, kecuali Kube-OVN dan Kube-Router. Kube-Router juga tidak dapat mendeteksi MTU, saya tidak menemukan cara untuk mengkonfigurasinya di mana pun dalam dokumentasi ( permintaan tentang topik ini terbuka).
Dalam hal konsumsi sumber daya, Cilium masih menggunakan lebih banyak RAM dibandingkan yang lain, namun pabrikan jelas menargetkan cluster besar, yang jelas tidak sama dengan pengujian pada cluster tiga node. Kube-OVN juga menghabiskan banyak sumber daya CPU dan RAM, tetapi ini adalah CNI muda yang berbasis Open vSwitch (seperti Antrea, kinerjanya lebih baik dan konsumsinya lebih sedikit).
Semua orang kecuali Flanel memiliki kebijakan jaringan. Kemungkinan besar dia tidak akan pernah mendukung mereka, karena tujuannya lebih sederhana daripada lobak kukus: semakin ringan, semakin baik.
Selain itu, kinerja enkripsinya juga luar biasa. Calico adalah salah satu CNI tertua, tetapi enkripsi baru ditambahkan beberapa minggu yang lalu. Mereka memilih wireguard daripada IPsec, dan sederhananya, ini berfungsi dengan baik dan luar biasa, benar-benar melampaui CNI lain dalam bagian pengujian ini. Tentu saja, konsumsi sumber daya meningkat karena enkripsi, namun throughput yang dicapai sepadan (Calico menunjukkan peningkatan enam kali lipat dalam pengujian enkripsi dibandingkan dengan Cilium, yang menempati peringkat kedua). Selain itu, Anda dapat mengaktifkan wireguard kapan saja setelah Anda menyebarkan Calico ke cluster, dan Anda juga dapat menonaktifkannya untuk waktu singkat atau permanen jika Anda mau. Tapi ini sangat nyaman! Kami mengingatkan Anda bahwa Calico saat ini tidak mendeteksi MTU secara otomatis (fitur ini direncanakan untuk versi mendatang), jadi pastikan untuk mengonfigurasi MTU jika jaringan Anda mendukung Jumbo Frames (MTU 9000).
Perlu diketahui bahwa Cilium dapat mengenkripsi lalu lintas antar node cluster (dan bukan hanya antar Pod), yang bisa menjadi sangat penting untuk node cluster publik.
Sebagai kesimpulan, saya menyarankan kasus penggunaan berikut:
- Perlu CNI untuk cluster yang sangat kecil ATAU saya tidak memerlukan keamanan: bekerja dengan Flanel, CNI paling ringan dan stabil (dia juga salah satu yang tertua, menurut legenda dia ditemukan oleh Homo Kubernautus atau Homo Contaitorus). Anda mungkin juga tertarik dengan proyek paling cerdik , memeriksa!
- Butuh CNI untuk cluster reguler: Belacu - pilihan Anda, tapi jangan lupa untuk mengkonfigurasi MTU jika diperlukan. Anda dapat dengan mudah dan alami bermain-main dengan kebijakan jaringan, mengaktifkan dan menonaktifkan enkripsi, dll.
- Membutuhkan CNI untuk cluster berskala (sangat) besar: Ya, pengujian tidak menunjukkan perilaku cluster besar, saya akan dengan senang hati melakukan pengujian, tetapi kami tidak memiliki ratusan server dengan koneksi 10Gbps. Jadi pilihan terbaik adalah menjalankan pengujian yang dimodifikasi pada node Anda, setidaknya dengan Calico dan Cilium.
Sumber: www.habr.com