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