Это обновление моего предыдущего бенчмарка, который теперь работает на 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