Хабрахабр

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

14 с актуальной версией CNI на апрель 2019 года. Это обновление моего предыдущего бенчмарка, который теперь работает на Kubernetes 1.

Во-первых, хочу поблагодарить команду Cilium: ребята помогли мне проверить и исправить скрипты мониторинга метрик.

Что изменилось с ноября 2018

Вот что изменилось с тех пор (если интересно):

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

Romana больше не поддерживается, так что мы удалили ее из бенчмарка.

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

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

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

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

Cilium предоставляет шифрование с IPSec-туннелями и предлагает альтернативу зашифрованной сети WeaveNet. Cilium теперь поддерживает шифрование! Но WeaveNet быстрее, чем Cilium с включенным шифрованием.

Cilium теперь проще деплоить — спасибо встроенному оператору ETCD.

Команда Cilium попыталась согнать со своего CNI вес, сократив потребляемую память и затраты ЦП, но конкуренты пока все равно легче.

Контекст бенчмарка

Серверы подключены к коммутатору напрямую через пассивные кабели DAC SFP+ и настроены в одном VLAN с jumbo-кадрами (MTU 9000). Бенчмарк проводится на трех не виртуализированных серверах Supermicro с коммутатором Supermicro на 10 Гбит.

14. Kubernetes 1. 04 LTS с Docker 18. 0 установлен на Ubuntu 18. 2 (версия Docker по умолчанию в этом выпуске). 09.

Для этого мы используем NodeSelector в деплоях Kubernetes. Чтобы улучшить воспроизводимость, мы решили всегда настраивать мастер на первой ноде, серверную часть бенчмарка размещать на втором сервере, а клиентскую — на третьем.

Результаты бенчмарка будем описывать по такой шкале:

Выбор CNI для бенчмарка

Из 9 CNI мы возьмем только 6: исключим те, которые сложно устанавливаются и/или не работают без настройки по документации (Romana, Contiv-VPP и JuniperContrail/TungstenFabric). Это бенчмарк только для CNI из списка в разделе о создании одного мастер-кластера с kubeadm в официальной документации Kubernetes.

Будем сравнивать следующие 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, тем лучше будет наше первое впечатление.

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

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


Как параметр MTU влияет на пропускную способность

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


CNI автоматически определяют MTU

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

Безопасность

Сравнивать безопасность CNI мы будем по двум аспектам: способности шифровать передаваемые данные и реализации сетевых политик Kubernetes (по реальным тестам, не по документации).

Шифрование WeaveNet включается через настройку пароля шифрования в качестве переменной окружения CNI. Только два CNI шифруют данные: Cilium и WeaveNet. Шифрование Cilium настраивается командами, путем создания секретов Kubernetes, и через модификацию daemonSet (чуть сложнее, чем в WeaveNet, зато у Cilium есть пошаговые инструкции). В документации WeaveNet это описано сложно, но делается всё просто.

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

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


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

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

Мы тестируем производительность TCP и UDP (с помощью iperf3), реальных приложений, например HTTP, (с Nginx и curl) или FTP (с vsftpd и curl) и, наконец, работу приложений с использованием шифрования на основе протокола SCP (используя клиент и сервер OpenSSH). Этот бенчмарк показывает среднюю пропускную способность минимум за три запуска каждого теста.

Тут мы используем такую же шкалу, но цветовую: Для всех тестов мы сделали бенчмарк на «голом железе» (зеленая строка), чтобы сравнить эффективность CNI с нативной производительностью сети.

  • Желтый = очень хорошо
  • Оранжевый = хорошо
  • Синий = так себе
  • Красный = плохо

(Примечание. Мы не будет брать неправильно настроенные CNI и покажем только результаты для CNI с корректным MTU. 4. Cilium неправильно считает MTU, если включить шифрование, так что придется вручную уменьшить MTU до 8900 в версии 1. 5, это делается автоматически.) В следующей версии, 1.

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


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

CNI с шифрованием сильно отстают, потому что шифрование — вещь дорогая. Все CNI хорошо показали себя в бенчмарке по TCP.


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

CNI с шифрованием показали почти одинаковый результат. Здесь тоже у всех CNI все хорошо. Не забудьте, что только Cilium и Flannel сами правильно определили MTU, и это их результаты без дополнительной настройки. Cilium чуть отстает от конкурентов, но это всего 2,3% от «голого железа», так что результат неплохой.

Как видим, для HTTP общая производительность чуть ниже, чем для TCP. Как насчет реального приложения? Здесь все неплохо справились. Даже если использовать HTTP с TCP, в бенчмарке TCP мы настроили iperf3, чтобы избежать медленного старта, а это повлияет на бенчмарк HTTP. Cilium и WeaveNet с шифрованием выглядят совсем печально. У Kube-router есть явное преимущество, а WeaveNet показал себя не с лучшей стороны: примерно на 20% хуже «голого железа».

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

Почти все CNI справляются, а WeaveNet снова отстает. С SCP сразу видно, во что нам обходится шифрование SSH. Cilium и WeaveNet с шифрованием ожидаемо хуже всех из-за двойного шифрования (SSH + CNI).

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

Потребление ресурсов

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

Вот среднее значение для оперативной памяти узлов (без буферов и кэша) в МБ во время передачи. Начнем с памяти.


Потребление памяти

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


Потребление ЦП

Сильно отстает WeaveNet с лишними 5%, а за ним Cilium — 7%. Calico, Canal, Flannel и Kube-router очень эффективно используют ЦП — всего на 2% больше, чем Kubernetes без CNI.

Вот итог по потреблению ресурсов:

Итоги

Таблица со всеми результатами:


Общие результаты бенчмарка

Заключение

Помните, что этот бенчмарк тестирует только пропускную способность одного соединения на очень маленьком кластере (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-кадры. Это многофункциональный инструмент, эффективный в плане потребления ресурсов, производительности и безопасности.

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть