Bu benim güncellemem Artık Kubernetes 1.14'te Nisan 2019 itibarıyla en son CNI sürümüyle çalışıyor.
Öncelikle Cilium ekibine teşekkür etmek istiyorum: adamlar ölçüm izleme komut dosyalarını kontrol etmeme ve düzeltmeme yardımcı oldu.
Kasım 2018'den bu yana neler değişti?
İşte o zamandan bu yana değişenler (eğer ilgileniyorsanız):
Flannel en hızlı ve en basit CNI arayüzü olmaya devam ediyor ancak yine de ağ politikalarını ve şifrelemeyi desteklemiyor.
Romana artık desteklenmediğinden onu karşılaştırma testinden kaldırdık.
WeaveNet artık Giriş ve Çıkış için ağ politikalarını destekliyor! Ancak verimlilik azaldı.
Calico'da en iyi performans için maksimum paket boyutunu (MTU) manuel olarak yapılandırmanız gerekir. Calico, CNI'yi yüklemek için iki seçenek sunar; böylece ayrı bir ETCD deposu olmadan da bunu yapabilirsiniz:
- durumu veri deposu olarak Kubernetes API'sinde depolama (küme boyutu < 50 düğüm);
- K8S API üzerindeki yükü hafifletmek için durumu Kubernetes API'de Typha proxy'li bir veri deposu olarak depolama (küme boyutu > 50 düğüm).
Calico desteğini açıkladı Uygulama düzeyinde güvenlik için Istio'nun üstünde.
Silium artık şifrelemeyi destekliyor! Cilium, IPSec tünelleri ile şifreleme sağlar ve şifrelenmiş WeaveNet ağına bir alternatif sunar. Ancak WeaveNet, şifreleme etkinken Cilium'dan daha hızlıdır.
Yerleşik ETCD operatörü sayesinde Cilium'un dağıtımı artık daha kolay.
Cilium ekibi, bellek tüketimini ve CPU maliyetlerini azaltarak CNI'nın ağırlığını bir miktar azaltmaya çalıştı ancak rakipleri hâlâ daha hafif.
Karşılaştırma bağlamı
Karşılaştırma, 10 Gb Supermicro anahtarına sahip, sanallaştırılmamış üç Supermicro sunucuda çalıştırılıyor. Sunucular, pasif DAC SFP+ kabloları aracılığıyla doğrudan anahtara bağlanır ve jumbo çerçevelerle (MTU 9000) aynı VLAN üzerinde yapılandırılır.
Docker 1.14.0 (bu sürümdeki varsayılan Docker sürümü) ile Ubuntu 18.04 LTS'ye yüklenen Kubernetes 18.09.2.
Tekrarlanabilirliği geliştirmek için, ana düğümü her zaman ilk düğümde yapılandırmaya, karşılaştırmanın sunucu kısmını ikinci sunucuya ve istemci kısmını da üçüncü sunucuya yerleştirmeye karar verdik. Bunu yapmak için Kubernetes dağıtımlarında NodeSelector kullanıyoruz.
Karşılaştırma sonuçlarını aşağıdaki ölçekte açıklayacağız:
Karşılaştırma için bir CNI seçme
Bu yalnızca bölümdeki listedeki CNI için bir kıyaslamadır Resmi Kubernetes belgelerine bakın. 9 CNI'den yalnızca 6'sını alacağız: kurulumu zor olanları ve/veya belgelere göre yapılandırma olmadan çalışmayanları hariç tutacağız (Romana, Contiv-VPP ve JuniperContrail/TungstenFabric).
Aşağıdaki CNI'leri karşılaştıracağız:
- Calico v3.6
- Canal v3.6 (esasen ağ iletişimi için Flanel + güvenlik duvarı olarak Calico)
- Silyum 1.4.2
- Flanel 0.11.0
- Kube yönlendirici 0.2.5
- WeaveNet 2.5.1
Montaj
CNI'nın kurulumu ne kadar kolay olursa, ilk izlenimimiz de o kadar iyi olacaktır. Karşılaştırmalı değerlendirmedeki tüm CNI'lerin kurulumu çok kolaydır (bir veya iki komutla).
Söylediğimiz gibi, sunucular ve anahtarlar jumbo çerçeveler etkin olacak şekilde yapılandırılmıştır (MTU'yu 9000'e ayarladık). CNI'nin adaptörlerin konfigürasyonuna göre MTU'yu otomatik olarak belirlemesi bizi mutlu eder. Ancak bunu yalnızca Cilium ve Flannel başardı. CNI'lerin geri kalanının GitHub'da otomatik MTU keşfi ekleme istekleri var, ancak Calico, Canal ve Kube yönlendirici için ConfigMap'i değiştirerek veya WeaveNet için bir ortam değişkeni ileterek bunu manuel olarak yapılandıracağız.
Yanlış MTU ile ilgili sorun nedir? Bu diyagram, varsayılan MTU ile etkinleştirilmiş jumbo çerçeveler ile WeaveNet arasındaki farkı gösterir:
MTU verimi nasıl etkiler?
MTU'nun performans açısından ne kadar önemli olduğunu gördük, şimdi CNI'larımızın bunu otomatik olarak nasıl belirlediğini görelim:
CNI, MTU'yu otomatik olarak algılar
Grafik, optimum performans için Calico, Canal, Kube-router ve WeaveNet için MTU'yu yapılandırmanız gerektiğini göstermektedir. Cilium ve Flannel, MTU'yu herhangi bir ayar yapmadan kendileri doğru bir şekilde belirlemeyi başardılar.
güvenlik
CNI güvenliğini iki açıdan karşılaştıracağız: iletilen verileri şifreleme yeteneği ve Kubernetes ağ politikalarının uygulanması (belgelere değil, gerçek testlere dayalı).
Yalnızca iki CNI verileri şifreler: Cilium ve WeaveNet. Şifreleme WeaveNet şifreleme parolasının bir CNI ortam değişkeni olarak ayarlanmasıyla etkinleştirilir. İÇİNDE WeaveNet bunu karmaşık bir şekilde açıklıyor ancak her şey basit bir şekilde yapılıyor. Şifreleme kirpik komutlarla, Kubernetes sırları oluşturularak ve daemonSet'te değişiklik yapılarak yapılandırılır (WeaveNet'tekinden biraz daha karmaşıktır ancak Cilium'un adım adım ).
Ağ politikasının uygulanmasına gelince, başarılı oldular Calico, Canal, Cilium ve WeaveNetGiriş ve Çıkış kurallarını yapılandırabileceğiniz yer. İçin Kube yönlendirici yalnızca Giriş için kurallar vardır ve flanel Hiçbir ağ politikası yoktur.
İşte genel sonuçlar:
Güvenlik Performansı Karşılaştırma Sonuçları
Proizvoditelnost
Bu kıyaslama, her testin en az üç çalıştırması boyunca ortalama verimi gösterir. TCP ve UDP'nin performansını (iperf3 kullanarak), HTTP gibi gerçek uygulamaları (Nginx ve curl ile) veya FTP'yi (vsftpd ve curl ile) ve son olarak SCP tabanlı şifrelemeyi kullanarak (istemci ve sunucu OpenSSH kullanarak) uygulama performansını test ediyoruz.
Tüm testler için, CNI performansını yerel ağ performansıyla karşılaştırmak üzere bir çıplak donanım kıyaslaması (yeşil çizgi) gerçekleştirdik. Burada aynı ölçeği kullanıyoruz, ancak renkli olarak:
- Sarı = çok iyi
- Turuncu = iyi
- Mavi = öyle öyle
- Kırmızı = kötü
Yanlış yapılandırılmış CNI'leri almayacağız ve yalnızca doğru MTU'ya sahip CNI'ların sonuçlarını göstereceğiz. (Not: Şifrelemeyi etkinleştirirseniz Cilium, MTU'yu doğru şekilde hesaplamaz, dolayısıyla 8900 sürümünde MTU'yu manuel olarak 1.4'e düşürmeniz gerekecektir. Bir sonraki sürüm olan 1.5, bunu otomatik olarak yapar.)
İşte sonuçlar:
TCP Performansı
Tüm CNI'ler TCP kıyaslamasında iyi performans gösterdi. Şifrelemeli CNI, şifreleme pahalı olduğundan çok geride kalıyor.
UDP performansı
Burada da tüm CNI'lar iyi durumda. Şifrelemeli CNI neredeyse aynı sonucu gösterdi. Cilium rakiplerinin biraz gerisinde ama çıplak metalin yalnızca %2,3'ünü oluşturuyor, dolayısıyla kötü bir sonuç değil. MTU'yu yalnızca Cilium ve Flannel'ın kendilerinin doğru şekilde belirlediğini ve bunların herhangi bir ek yapılandırma gerektirmeden sonuçları olduğunu unutmayın.
Gerçek bir uygulamaya ne dersiniz? Gördüğünüz gibi HTTP'nin genel performansı TCP'ye göre biraz daha düşük. HTTP'yi TCP ile kullansanız bile, HTTP karşılaştırmasını etkileyebilecek yavaş bir başlatmayı önlemek için TCP karşılaştırmasında iperf3'ü yapılandırdık. Burada herkes iyi iş çıkardı. Kube yönlendiricinin açık bir avantajı var, ancak WeaveNet iyi performans göstermedi: çıplak metalden yaklaşık %20 daha kötü. Cilium ve WeaveNet şifrelemeli gerçekten üzücü görünüyor.
Başka bir TCP tabanlı protokol olan FTP ile sonuçlar farklılık gösterir. Flannel ve Kube yönlendirici işi yapıyor ancak Calico, Canal ve Cilium biraz geride ve çıplak metalden yaklaşık %10 daha yavaş. WeaveNet %17'ye varan oranda geridedir ancak şifrelenmiş WeaveNet, şifrelenmiş Cilium'un %40 önündedir.
SCP ile SSH şifrelemenin bize ne kadara mal olduğunu hemen görebiliriz. Neredeyse tüm CNI'ler iyi durumda ancak WeaveNet yine geride kalıyor. Şifrelemeli Cilium ve WeaveNet, çift şifreleme (SSH + CNI) nedeniyle beklenen en kötüler.
İşte sonuçları içeren bir özet tablo:
Kaynak tüketimi
Şimdi CNI'nin ağır yükler altında (TCP aktarımı sırasında, 10 Gbps) kaynakları nasıl tükettiğini karşılaştıralım. Performans testlerinde CNI'yı çıplak metal (yeşil çizgi) ile karşılaştırıyoruz. Kaynak tüketimi için CNI'sız saf Kubernetes'i (mor çizgi) gösterelim ve CNI'nın ne kadar ekstra kaynak tükettiğini görelim.
Bellekle başlayalım. Aktarım sırasında düğümlerin RAM'inin (arabellekler ve önbellek hariç) MB cinsinden ortalama değeri burada verilmiştir.
Bellek tüketimi
Flannel ve Kube-yönlendirici mükemmel sonuçlar verdi - yalnızca 50 MB. Calico ve Canal'ın her birinde 70 tane var. WeaveNet açıkça diğerlerinden daha fazla tüketiyor - 130 MB ve Cilium 400 kadarını kullanıyor.
Şimdi CPU zaman tüketimini kontrol edelim. dikkate değer: Diyagram yüzdeleri değil, ppm'yi göstermektedir, yani “çıplak demir” için 38 ppm %3,8'dir. Sonuçlar burada:
CPU tüketimi
Calico, Canal, Flannel ve Kube-router CPU açısından oldukça verimlidir; CNI'sız Kubernetes'ten yalnızca %2 daha fazla. WeaveNet ekstra %5 ile çok geride kalıyor ve onu %7 ile Cilium takip ediyor.
Kaynak tüketiminin bir özetini burada bulabilirsiniz:
sonuçlar
Tüm sonuçları içeren tablo:
Genel kıyaslama sonuçları
Sonuç
Son bölümde sonuçlara ilişkin subjektif fikrimi dile getireceğim. Bu kıyaslamanın yalnızca çok küçük bir kümedeki (3 düğüm) tek bir bağlantının verimini test ettiğini unutmayın. Büyük kümeler (<50 düğüm) veya paralel bağlantılar için geçerli değildir.
Senaryoya bağlı olarak aşağıdaki CNI'leri kullanmanızı öneririm:
- Kümenizde var mı az kaynağa sahip düğümler (birkaç GB RAM, birkaç çekirdek) ve güvenlik özelliklerine ihtiyacınız yok; flanel. Bu, en uygun maliyetli CNI'lerden biridir. Ayrıca çok çeşitli mimarilerle (amd64, arm, arm64 vb.) uyumludur. Ayrıca bu, MTU'yu otomatik olarak belirleyebilen iki CNI'den biridir (diğeri Cilium'dur), dolayısıyla hiçbir şeyi yapılandırmanıza gerek yoktur. Kube yönlendirici de uygundur ancak standart değildir ve MTU'yu manuel olarak yapılandırmanız gerekecektir.
- Gerekirse ağı şifrelemek güvenlik için al WeaveNet. Jumbo çerçeveler kullanıyorsanız MTU boyutunu belirtmeyi ve ortam değişkeni aracılığıyla parola belirleyerek şifrelemeyi etkinleştirmeyi unutmayın. Ancak performansı unutmak daha iyidir; şifrelemenin maliyeti budur.
- için normal kullanım советую patiska. Bu CNI, çeşitli Kubernetes dağıtım araçlarında (Kops, Kubespray, Rancher, vb.) yaygın olarak kullanılmaktadır. WeaveNet'te olduğu gibi, jumbo çerçeveler kullanılıyorsa MTU'yu ConfigMap'te yapılandırdığınızdan emin olun. Kaynak tüketimi, performans ve güvenlik açısından verimli, çok işlevli bir araçtır.
Son olarak gelişmeleri takip etmenizi tavsiye ederim kirpik. Bu CNI'nin ürünleri üzerinde (özellikler, kaynak tasarrufu, performans, güvenlik, kümeleme...) çok çalışan çok aktif bir ekibi var ve çok ilginç planları var.
CNI seçimi için görsel diyagram
Kaynak: habr.com