Результати бенчмарку мережевих плагінів Kubernetes (CNI) по мережі 10 Гбіт/с (оновлено: квітень 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 із комутатором Supermicro на 10 Гбіт. Сервери підключені безпосередньо до комутатора через пасивні кабелі DAC SFP+ і налаштовані в одному VLAN з jumbo-кадрами (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 як міжмережевий екран)
• Cilium 1.4.2
• Flannel 0.11.0
• Kube-router 0.2.5
• WeaveNet 2.5.1

Встановлення

Чим простіше встановити CNI, краще буде наше перше враження. Всі CNI з бенчмарку дуже просто встановлювати (одною-двома командами).

Як ми сказали, сервери та комутатор налаштовані з активованими jumbo-кадрами (ми встановили MTU 9000). Ми були б раді, якби CNI автоматично визначив MTU, виходячи з налаштування адаптерів. Однак із цим впоралися лише Cilium та Flannel. Інші CNI мають запити в GitHub для додавання автоматичного виявлення MTU, на ми будемо налаштовувати його вручну, змінивши ConfigMap для Calico, Canal і Kube-router, або передаючи змінну оточення для WeaveNet.

У чому проблема неправильного MTU? На цій діаграмі видно різницю між WeaveNet з MTU за замовчуванням та з включеними jumbo-кадрами:

Як параметр MTU впливає пропускну здатність

Ми розібралися, наскільки важливий MTU для продуктивності, а тепер давайте подивимося, як наші CNI автоматично визначають його:

CNI автоматично визначають MTU

На графіку видно, що потрібно налаштувати MTU для Calico, Canal, Kube-router та WeaveNet для оптимальної продуктивності. Cilium та Flannel зуміли самі правильно визначити MTU без жодних налаштувань.

Безпека

Порівнювати безпеку CNI ми будемо за двома аспектами: здатністю шифрувати передані дані та реалізації мережевих політик Kubernetes (за реальними тестами, не за документацією).

Лише два CNI шифрують дані: Cilium та WeaveNet. Шифрування WeaveNet включається через налаштування пароля шифрування як змінне оточення CNI. У документації WeaveNet це складно описано, але просто робиться все просто. Шифрування Циліум налаштовується командами, шляхом створення секретів Kubernetes, і через модифікацію daemonSet (трохи складніше, ніж у WeaveNet, зате Cilium має покрокові інструкції).

Що ж до реалізації мережної політики, то тут досягли успіху Calico, Canal, Cilium та WeaveNet, в яких можна настроювати правила Ingress та Egress. Для Kube-router є правила тільки для 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, у бенчмарку TCP ми налаштували iperf3, щоб уникнути повільного старту, а це вплине на бенчмарк HTTP. Тут усі непогано впоралися. Kube-router має явну перевагу, а WeaveNet показав себе не з кращого боку: приблизно на 20% гірше «голого заліза». Cilium і WeaveNet із шифруванням виглядають дуже сумно.

З FTP, ще одним протоколом на основі TCP, результати відрізняються. Flannel і Kube-router справляються, а Calico, Canal і Cilium трохи відстають і працюють приблизно на 10% повільніше від «голого заліза». WeaveNet не встигає на цілих 17%, зате WeaveNet із шифруванням на 40% випереджає зашифрований Cilium.

З SCP відразу видно, що нам обходиться шифрування SSH. Багато CNI справляються, а WeaveNet знову відстає. Cilium і WeaveNet з шифруванням очікувано найгірше через подвійне шифрування (SSH + CNI).

Ось зведена таблиця з результатами:

Споживання ресурсів

Тепер давайте порівняємо, як CNI споживають ресурси при важких навантаженнях (під час передачі TCP, 10 Гбіт/с). У тестах продуктивності ми порівнюємо CNI із «голим залізом» (зелений рядок). Для споживання ресурсів покажемо чистий Kubernetes (фіолетовий рядок) без CNI та подивимося, скільки зайвих ресурсів споживає CNI.

Почнемо з пам'яті. Ось середнє значення для оперативної пам'яті вузлів (без буферів та кешу) у МБ під час передачі.

Споживання пам'яті

Flannel і Kube-router показали відмінний результат – лише 50 МБ. У Calico і Canal – по 70. WeaveNet явно споживає більше за інших – 130 МБ, а Cilium використовує цілих 400.
Тепер перевіримо споживання процесорного часу. Примітки: на діаграмі не відсотки, а проміле, тобто 38 проміле для «голого заліза» — це 3,8% Ось результати:

Споживання ЦП

Calico, Canal, Flannel та Kube-router дуже ефективно використовують ЦП – всього на 2% більше, ніж Kubernetes без CNI. Сильно відстає WeaveNet із зайвими 5%, а за ним Cilium – 7%.

Ось результат із споживання ресурсів:

Підсумки

Таблиця з усіма результатами:

Загальні результати бенчмарку

Висновок

В останній частині я висловлю свою суб'єктивну думку про результати. Пам'ятайте, що цей бенчмарк тестує лише пропускну здатність одного з'єднання на дуже маленькому кластері (3 вузли). Він не поширюється на великі кластери (<50 вузлів) або на паралельні підключення.

Я раджу використовувати наступні CNI залежно від сценарію:

• У вас у кластері є вузли з невеликою кількістю ресурсів (кілька ГБ оперативної пам'яті, кілька ядер) і вам не потрібні функції безпеки - вибирайте Фланель. Це один із найбільш економічних CNI. І він сумісний з різними архітектурами (amd64, arm, arm64 і т. д.). До того ж це один із двох (другий — Cilium) CNI, який може автоматично визначити MTU, тож нічого налаштовувати не доведеться. Kube-router теж підходить, але він не такий стандартний і потрібно вручну налаштовувати MTU.
• Якщо потрібно зашифрувати мережу для безпеки, беріть WeaveNet. Не забудьте вказати розмір MTU, якщо ви використовуєте jumbo-кадри, і активувати шифрування, вказавши пароль через змінну оточення. Але про продуктивність краще забути така плата за шифрування.
• Для звичайного застосування Советую коленкор. Цей CNI широко використовується у різних інструментах деплою Kubernetes (Kops, Kubespray, Rancher тощо). Як і WeaveNet, не забудьте налаштувати MTU в ConfigMap, якщо використовуєте jumbo-кадри. Це багатофункціональний інструмент, ефективний у плані споживання ресурсів, продуктивності та безпеки.

І, нарешті, раджу стежити за розвитком Циліум. Цей CNI має дуже активну команду, яка багато працює над своїм продуктом (функції, економія ресурсів, продуктивність, безпека, розподіл за кластерами…), і у них дуже цікаві плани.

Наочна схема для вибору CNI

Джерело: habr.com