🥇Резултати от сравнителен тест на приставката за мрежа Kubernetes (CNI) над 10 Gbps мрежа (Актуализирано: април 2019 г.)

Това е моята актуализация предишен бенчмарк, който сега работи на Kubernetes 1.14 с най-новата CNI версия от април 2019 г.

Първо, искам да благодаря на екипа на Cilium: момчетата ми помогнаха да проверя и коригирам скриптовете за наблюдение на показателите.

Какво се промени от ноември 2018 г

Ето какво се е променило оттогава (ако се интересувате):

Flannel остава най-бързият и прост CNI интерфейс, но все още не поддържа мрежови политики и криптиране.

Romana вече не се поддържа, затова я премахнахме от бенчмарка.

WeaveNet вече поддържа мрежови политики за Ingress и Egress! Но производителността е намаляла.

В Calico все още трябва ръчно да конфигурирате максималния размер на пакета (MTU) за най-добра производителност. Calico предлага две опции за инсталиране на CNI, така че можете да се справите без отделно ETCD хранилище:

съхраняване на състоянието в Kubernetes API като хранилище на данни (размер на клъстера < 50 възела);
съхраняване на състояние в Kubernetes API като хранилище на данни с Typha прокси за облекчаване на натоварването на K8S API (размер на клъстера > 50 възела).

Calico обяви поддръжка политики на ниво приложение върху Istio за сигурност на ниво приложение.

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 от списъка в раздела относно създаването на един главен клъстер с kubeadm Вижте официалната документация на Kubernetes. От 9-те CNI ще вземем само 6: ще изключим тези, които са трудни за инсталиране и/или не работят без конфигурация според документацията (Romana, Contiv-VPP и JuniperContrail/TungstenFabric).

Ще сравним следните 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 автоматично го определят:

CNI автоматично открива MTU

Графиката показва, че трябва да конфигурирате MTU за Calico, Canal, Kube-router и WeaveNet за оптимална производителност. Cilium и Flannel успяха сами да определят правилно MTU без никакви настройки.

сигурност

Ще сравним сигурността на CNI в два аспекта: способността за криптиране на предадени данни и прилагането на мрежовите политики на Kubernetes (базирани на реални тестове, а не на документация).

Само две CNI криптират данни: Cilium и WeaveNet. Шифроване WeaveNet активиран чрез задаване на паролата за шифроване като променлива на CNI среда. IN документация WeaveNet го описва по сложен начин, но всичко се прави просто. Шифроване цилиума конфигуриран чрез команди, чрез създаване на тайни на Kubernetes и чрез модификация на daemonSet (малко по-сложно, отколкото в WeaveNet, но Cilium има стъпка по стъпка Directions).

Що се отнася до прилагането на мрежовата политика, те успяха 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, прави това автоматично.)

Ето резултатите:

TCP производителност

Всички CNI се представиха добре в TCP бенчмарка. CNI с криптиране изостава много, защото криптирането е скъпо.

UDP производителност

И тук всички 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%.

Ето обобщение на потреблението на ресурси: