TL; DR: Всички CNI работят както трябва, с изключение на Kube-Router и Kube-OVN, Calico, с изключение на автоматичното откриване на MTU, е най-добрият.
Статия-актуализация на миналите ми проверки ( и ), по време на тестването използвам Kubernetes 1.19 на Ubuntu 18.04 с актуализирани CNI от август 2020 г.
Преди да се потопим в показателите...
Какво е новото от април 2019 г.?
- Можете да тествате на собствен клъстер: Можете да провеждате тестове на собствен клъстер с помощта на нашия инструмент Мрежов бенчмарк Kubernetes:
- Появиха се нови членове
- от VMware Tanzu
- от alauda.io
- Нови сценарии: Текущите проверки изпълняват тестове за мрежова производителност „Pod-to-Pod“ и е добавен нов скрипт „Pod-to-Service“, който изпълнява тестове, по-близки до условията в реалния свят. На практика вашият Pod с API работи с базата като услуга, а не чрез ip адреса на Pod (разбира се, ние проверяваме TCP и UDP и за двата сценария).
- Консумация на ресурси: всеки тест вече има свое собствено сравнение на ресурси
- Премахване на тестове за приложения: Вече не правим HTTP, FTP и SCP тестове, тъй като нашето ползотворно сътрудничество с общността и поддържащите CNI разкри празнина между резултатите от iperf през TCP и резултатите от curl поради забавяне на стартирането на CNI (първите няколко секунди на Pod стартиране, което не е типично в реални условия).
- Отворен код: налични са всички тестови източници (скриптове, настройки на yml и оригинални „сурови“ данни).
Референтен тестов протокол
Протоколът е описан подробно Моля, имайте предвид, че тази статия е за Ubuntu 18.04 с ядрото по подразбиране.
Избор на CNI за оценка
Това тестване е насочено към сравняване на CNI, конфигурирани с един yaml файл (следователно всички инсталирани от скриптове, като VPP и други, са изключени).
Нашите избрани CNI за сравнение:
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (мрежа Flannel + мрежови правила на Calico)
- Реснички 1.8.2
- Фланела 0.12.0
- Най-новият Kube-рутер (2020–08–25)
- WeaveNet 2.7.0
Конфигуриране на MTU за CNI
На първо място, проверяваме влиянието на автоматичното откриване на MTU върху производителността на TCP:
Влияние на MTU върху производителността на TCP
Още по-голяма празнина се открива при използване на UDP:
Влияние на MTU върху производителността на UDP
Предвид ОГРОМНОТО въздействие върху производителността, разкрито в тестовете, бихме искали да изпратим писмо с надежда до всички поддържащи CNI: моля, добавете автоматично откриване на MTU към CNI. Ще спасите котенца, еднорози и дори най-сладкото: малкия Девоп.
Въпреки това, ако трябва да използвате CNI без поддръжка за автоматично откриване на MTU, можете да го конфигурирате ръчно, за да получите производителност. Моля, имайте предвид, че това се отнася за Calico, Canal и WeaveNet.
Моята малка молба към придружаващите CNI...
CNI тестване: необработени данни
В този раздел ще сравним CNI с правилното MTU (определено автоматично или зададено ръчно). Основната цел тук е да се покажат необработените данни в графики.
Цветна легенда:
- сиво - проба (т.е. голо желязо)
- зелено - честотна лента над 9500 Mbps
- жълто - честотна лента над 9000 Mbps
- оранжево - честотна лента над 8000 Mbps
- червено - честотна лента под 8000 Mbps
- синьо - неутрално (не е свързано с честотната лента)
Консумация на ресурси без натоварване
Първо, проверете консумацията на ресурси, когато клъстерът „спи“.
Консумация на ресурси без натоварване
Под-към-под
Този сценарий предполага, че клиентският Pod се свързва директно със сървърния Pod, използвайки своя IP адрес.
Сценарий от под към под
TCP
TCP резултати от Pod-to-Pod и съответно потребление на ресурси:
UDP
Pod-to-Pod UDP резултати и съответно потребление на ресурси:
Pod-to-Service
Този раздел е подходящ за случаи на реална употреба, клиентският Pod се свързва със сървърния Pod чрез услугата ClusterIP.
Скрипт от Pod-to-Service
TCP
TCP резултати от Pod-to-Service и съответно потребление на ресурси:
UDP
Pod-to-Service UDP резултати и съответно потребление на ресурси:
Поддръжка на мрежова политика
Сред всички по-горе, единственият, който не подкрепя политиката, е Фланела. Всички останали правилно прилагат мрежови политики, включително входящи и изходящи. Добра работа!
CNI криптиране
Сред проверените CNI има такива, които могат да криптират мрежов обмен между Pods:
- Antrea използва IPsec
- Калико, използващ wireguard
- Cilium с помощта на IPsec
- WeaveNet с помощта на IPsec
капацитет
Тъй като са останали по-малко CNI, нека поставим всички сценарии в една графика:
Консумация на ресурси
В този раздел ще оценим ресурсите, използвани при обработката на комуникация Pod-to-Pod в TCP и UDP. Няма смисъл да се чертае графика Pod-to-Service, тъй като тя не предоставя допълнителна информация.
Сглобяване на всичко
Нека се опитаме да повторим всички графики, тук въведохме малко субективизъм, заменяйки действителните стойности с думите „много бързо“, „ниско“ и т.н.
Заключение и моите заключения
Това е малко субективно, тъй като предавам собствената си интерпретация на резултатите.
Радвам се, че се появиха нови CNI, Antrea се представи добре, много функции бяха внедрени дори в ранните версии: автоматично откриване на MTU, криптиране и лесна инсталация.
Ако сравним производителността, всички CNI работят добре, с изключение на Kube-OVN и Kube-Router. Kube-Router също не успя да открие MTU, не намерих начин да го конфигурирам никъде в документацията ( заявка по тази тема е отворена).
По отношение на потреблението на ресурси, Cilium все още използва повече RAM от други, но производителят очевидно се насочва към големи клъстери, което очевидно не е същото като тест на клъстер с три възела. Kube-OVN също консумира много CPU и RAM ресурси, но е млад CNI, базиран на Open vSwitch (като Antrea, той се представя по-добре и консумира по-малко).
Всички с изключение на Flannel имат мрежови политики. Много е вероятно той никога да не ги подкрепи, тъй като целта е по-проста от задушена ряпа: колкото по-лека, толкова по-добре.
Също така, наред с други неща, ефективността на криптиране е невероятна. Calico е един от най-старите CNI, но криптирането беше добавено едва преди няколко седмици. Те избраха wireguard вместо IPsec и просто казано, работи страхотно и невероятно, напълно засенчвайки други CNI в тази част от тестването. Разбира се, потреблението на ресурси се увеличава поради криптирането, но постигнатата производителност си заслужава (Calico показа шесткратно подобрение в теста за криптиране в сравнение с Cilium, който се класира на второ място). Освен това можете да активирате wireguard по всяко време, след като разположите Calico в клъстера, и можете също да го деактивирате за кратко или постоянно, ако желаете. Все пак е невероятно удобно! Напомняме ви, че Calico в момента не открива автоматично MTU (тази функция е планирана за бъдещи версии), така че не забравяйте да конфигурирате MTU, ако вашата мрежа поддържа Jumbo Frames (MTU 9000).
Освен всичко друго, имайте предвид, че Cilium може да криптира трафика между клъстерните възли (а не само между Pods), което може да бъде много важно за обществените клъстерни възли.
Като заключение предлагам следните случаи на употреба:
- Имам нужда от CNI за много малък клъстер ИЛИ нямам нужда от сигурност: работи с бархет, най-лекият и стабилен CNI (той също е един от най-старите, според легендата е изобретен от Homo Kubernautus или Homo Contaitorus). Може да се интересувате и от най-гениалния проект , провери!
- Нуждаете се от CNI за обикновен клъстер: американ - ваш избор, но не забравяйте да конфигурирате MTU, ако е необходимо. Можете лесно и естествено да си играете с мрежовите политики, да включвате и изключвате криптирането и т.н.
- Нуждаете се от CNI за (много) голям клъстер: Е, тестът не показва поведението на големи клъстери, ще се радвам да проведа тестове, но нямаме стотици сървъри с 10Gbps връзка. Така че най-добрият вариант е да стартирате модифициран тест на вашите възли, поне с Calico и Cilium.
Източник: www.habr.com