Това е моята актуализация
Първо, искам да благодаря на екипа на Cilium: момчетата ми помогнаха да проверя и коригирам скриптовете за наблюдение на показателите.
Какво се промени от ноември 2018 г
Ето какво се е променило оттогава (ако се интересувате):
Flannel остава най-бързият и прост CNI интерфейс, но все още не поддържа мрежови политики и криптиране.
Romana вече не се поддържа, затова я премахнахме от бенчмарка.
WeaveNet вече поддържа мрежови политики за Ingress и Egress! Но производителността е намаляла.
В Calico все още трябва ръчно да конфигурирате максималния размер на пакета (MTU) за най-добра производителност. Calico предлага две опции за инсталиране на CNI, така че можете да се справите без отделно ETCD хранилище:
- съхраняване на състоянието в Kubernetes API като хранилище на данни (размер на клъстера < 50 възела);
- съхраняване на състояние в Kubernetes API като хранилище на данни с Typha прокси за облекчаване на натоварването на K8S API (размер на клъстера > 50 възела).
Calico обяви поддръжка
Cilium вече поддържа криптиране! Cilium осигурява криптиране с IPSec тунели и предлага алтернатива на криптираната мрежа WeaveNet. Но WeaveNet е по-бърз от Cilium с активирано криптиране.
Cilium вече е по-лесен за внедряване благодарение на вградения ETCD оператор.
Екипът на Cilium се опита да намали малко теглото на своя CNI чрез намаляване на потреблението на памет и разходите за процесор, но конкурентите му все още са по-леки.
Контекст на бенчмарк
Бенчмаркът се изпълнява на три невиртуализирани Supermicro сървъра с 10 Gb Supermicro суич. Сървърите са свързани директно към комутатора чрез пасивни DAC SFP+ кабели и са конфигурирани на една и съща VLAN с jumbo frames (MTU 9000).
Kubernetes 1.14.0 е инсталиран на Ubuntu 18.04 LTS с Docker 18.09.2 (версията на Docker по подразбиране в тази версия).
За да подобрим възпроизводимостта, решихме винаги да конфигурираме главния на първия възел, да поставим сървърната част от бенчмарка на втория сървър и клиентската част на третия. За да направим това, използваме NodeSelector в внедряванията на Kubernetes.
Ще опишем резултатите от бенчмарка в следната скала:
Избор на CNI за бенчмарк
Това е бенчмарк само за CNI от списъка в раздела
Ще сравним следните CNI:
- Calico v3.6
- Canal v3.6 (по същество Flannel за работа в мрежа + Calico като защитна стена)
- Реснички 1.4.2
- Фланела 0.11.0
- Kube-рутер 0.2.5
- WeaveNet 2.5.1
Инсталация
Колкото по-лесно се инсталира CNI, толкова по-добро ще бъде първото ни впечатление. Всички CNI от бенчмарка са много лесни за инсталиране (с една или две команди).
Както казахме, сървърите и комутаторът са конфигурирани с активирани джъмбо рамки (настроихме MTU на 9000). Ще се радваме, ако CNI автоматично определи MTU въз основа на конфигурацията на адаптерите. Това обаче успяха само Cilium и Flannel. Останалите CNI имат заявки в GitHub за добавяне на автоматично откриване на MTU, но ние ще го конфигурираме ръчно, като променим ConfigMap за Calico, Canal и Kube-router или подадем променлива на средата за WeaveNet.
Какъв е проблемът с неправилното MTU? Тази диаграма показва разликата между WeaveNet с активирани MTU по подразбиране и джъмбо рамки:
Как MTU влияе на пропускателната способност?
Видяхме колко важен е MTU за производителността, сега нека видим как нашите CNI автоматично го определят:
Графиката показва, че трябва да конфигурирате MTU за Calico, Canal, Kube-router и WeaveNet за оптимална производителност. Cilium и Flannel успяха сами да определят правилно MTU без никакви настройки.
сигурност
Ще сравним сигурността на CNI в два аспекта: способността за криптиране на предадени данни и прилагането на мрежовите политики на Kubernetes (базирани на реални тестове, а не на документация).
Само две CNI криптират данни: Cilium и WeaveNet. Шифроване WeaveNet активиран чрез задаване на паролата за шифроване като променлива на CNI среда. IN
Що се отнася до прилагането на мрежовата политика, те успяха Calico, Canal, Cilium и WeaveNet, в който можете да конфигурирате правила за влизане и излизане. За Kube-рутер има правила само за Ingress и бархет Изобщо няма мрежови политики.
Ето общите резултати:
Резултати от теста за ефективност на безопасността
продуктивност
Този бенчмарк показва средната пропускателна способност за поне три изпълнения на всеки тест. Ние тестваме производителността на TCP и UDP (използвайки iperf3), реални приложения като HTTP (с Nginx и curl) или FTP (с vsftpd и curl) и накрая производителността на приложенията, използвайки SCP-базирано криптиране (използвайки клиент и сървър OpenSSH).
За всички тестове изпълнихме бенчмарк (зелена линия), за да сравним производителността на CNI с производителността на собствената мрежа. Тук използваме същата скала, но в цвят:
- Жълто = много добро
- Оранжево = добро
- Синьо = така-така
- Червено = лошо
Ние няма да вземем неправилно конфигурирани CNI и ще покажем резултати само за CNI с правилното MTU. (Забележка: Cilium не изчислява правилно MTU, ако активирате криптиране, така че ще трябва ръчно да намалите MTU до 8900 във версия 1.4. Следващата версия, 1.5, прави това автоматично.)
Ето резултатите:
Всички CNI се представиха добре в TCP бенчмарка. CNI с криптиране изостава много, защото криптирането е скъпо.
И тук всички CNI се справят добре. CNI с криптиране показа почти същия резултат. Cilium е малко по-назад от конкуренцията, но е само 2,3% гол метал, така че не е лош резултат. Не забравяйте, че само Cilium и Flannel определят MTU правилно сами и това са техните резултати без никаква допълнителна конфигурация.
Какво ще кажете за истинско приложение? Както можете да видите, общата производителност за HTTP е малко по-ниска от тази за TCP. Дори ако използвате HTTP с TCP, ние конфигурирахме iperf3 в TCP бенчмарка, за да избегнем бавно стартиране, което би повлияло на HTTP бенчмарка. Тук всички свършиха добра работа. Kube-рутерът има ясно предимство, но WeaveNet не се представи добре: около 20% по-лошо от голото състояние. Cilium и WeaveNet с криптиране изглеждат наистина тъжни.
С FTP, друг TCP-базиран протокол, резултатите варират. Flannel и Kube-router вършат работа, но Calico, Canal и Cilium са малко по-назад и са с около 10% по-бавни от bare metal. WeaveNet изостава с цели 17%, но криптираният WeaveNet е с 40% пред криптирания Cilium.
С SCP можем веднага да видим колко ни струва SSH криптирането. Почти всички CNI се справят добре, но WeaveNet отново изостава. Cilium и WeaveNet с криптиране очаквано са най-лошите поради двойното криптиране (SSH + CNI).
Ето обобщена таблица с резултатите:
Консумация на ресурси
Сега нека сравним как CNI консумира ресурси при големи натоварвания (по време на TCP трансфер, 10 Gbps). В тестовете за производителност сравняваме CNI с гол метал (зелена линия). За потребление на ресурси, нека покажем чист Kubernetes (лилава линия) без CNI и да видим колко допълнителни ресурси консумира CNI.
Да започнем с паметта. Ето средната стойност за RAM на възлите (с изключение на буферите и кеша) в MB по време на прехвърляне.
Flannel и Kube-router показаха отлични резултати - само 50 MB. Calico и Canal имат по 70. WeaveNet явно консумира повече от останалите - 130 MB, а Cilium използва цели 400.
Сега нека проверим консумацията на време на процесора. Забележително: диаграмата показва не проценти, а ppm, тоест 38 ppm за „голо желязо“ е 3,8%. Ето резултатите:
Calico, Canal, Flannel и Kube-router са много ефективни на процесора - само с 2% повече от Kubernetes без CNI. WeaveNet изостава далеч с допълнителни 5%, следван от Cilium със 7%.
Ето обобщение на потреблението на ресурси:
Резултати от
Таблица с всички резултати:
Заключение
В последната част ще изкажа моето субективно мнение за резултатите. Не забравяйте, че този бенчмарк тества пропускателната способност само на една връзка на много малък клъстер (3 възела). Не се прилага за големи клъстери (<50 възли) или паралелни връзки.
Препоръчвам да използвате следните CNI в зависимост от сценария:
- Имате ли във вашия клъстер възли с малко ресурси (няколко GB RAM, няколко ядра) и нямате нужда от функции за сигурност - изберете бархет. Това е един от най-рентабилните CNI. И е съвместим с голямо разнообразие от архитектури (amd64, arm, arm64 и др.). В допълнение, това е един от двата (другият е Cilium) CNI, които могат автоматично да определят MTU, така че не е нужно да конфигурирате нищо. Kube-рутерът също е подходящ, но не е стандартен и ще трябва ръчно да конфигурирате MTU.
- Ако е необходимо криптирайте мрежата за безопасност, вземете WeaveNet. Не забравяйте да посочите размера на MTU, ако използвате jumbo frames, и активирайте криптирането, като посочите парола чрез променлива на средата. Но е по-добре да забравите за производителността - това е цената на криптирането.
- За нормална употреба советую американ. Този CNI се използва широко в различни инструменти за внедряване на Kubernetes (Kops, Kubespray, Rancher и др.). Както при WeaveNet, не забравяйте да конфигурирате MTU в ConfigMap, ако използвате jumbo frames. Това е многофункционален инструмент, който е ефективен по отношение на потребление на ресурси, производителност и сигурност.
И накрая, съветвам ви да следите развитието цилиума. Този CNI има много активен екип, който работи много върху техния продукт (функции, спестяване на ресурси, производителност, сигурност, групиране...) и имат много интересни планове.
Визуална диаграма за избор на CNI
Източник: www.habr.com