Результаты бенчмарка сетевых плагинов Kubernetes (CNI) по сети 10 Гбит/с (обновлено: апрель 2019) +22



Это обновление моего предыдущего бенчмарка, который теперь работает на 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 это описано сложно, но делается всё просто. Шифрование Cilium настраивается командами, путем создания секретов Kubernetes, и через модификацию daemonSet (чуть сложнее, чем в WeaveNet, зато у Cilium есть пошаговые инструкции).


Что же касается реализации сетевой политики, то здесь преуспели Calico, Canal, Cilium и WeaveNet, в которых можно настраивать правила Ingress и Egress. Для Kube-router есть правила только для Ingress, а у Flannel вообще нет сетевых политик.


Вот общие результаты:



Результаты бенчмарка по характеристикам безопасности


Производительность


Этот бенчмарк показывает среднюю пропускную способность минимум за три запуска каждого теста. Мы тестируем производительность 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 в зависимости от сценария:


  • У вас в кластере есть узлы с небольшим количеством ресурсов (несколько ГБ оперативки, несколько ядер) и вам не нужны функции безопасности — выбирайте Flannel. Это один из самых экономичных CNI. И он совместим с самыми разными архитектурами (amd64, arm, arm64 и т. д.). К тому же это один из двух (второй — Cilium) CNI, который может автоматически определить MTU, так что ничего настраивать не придется. Kube-router тоже подходит, но он не такой стандартный и будет нужно вручную настраивать MTU.
  • Если нужно зашифровать сеть для безопасности, берите WeaveNet. Не забудьте указать размер MTU, если используете jumbo-кадры, и активировать шифрование, указав пароль через переменную окружения. Но о производительности лучше забыть — такова плата за шифрование.
  • Для обычного применения советую Calico. Этот CNI широко используется в разных инструментах деплоя Kubernetes (Kops, Kubespray, Rancher и т. д.). Как и с WeaveNet, не забудьте настроить MTU в ConfigMap, если используете jumbo-кадры. Это многофункциональный инструмент, эффективный в плане потребления ресурсов, производительности и безопасности.

И, наконец, советую следить за развитием Cilium. У этого CNI очень активная команда, которая много работает над своим продуктом (функции, экономия ресурсов, производительность, безопасность, распределение по кластерам…), и у них очень интересные планы.



Наглядная схема для выбора CNI




К сожалению, не доступен сервер mySQL