11.09.2020 20:00
Finnix 2 1900 Источник


TL;DR: Все CNI работают как надо, за исключением Kube-Router и Kube-OVN, Calico за исключением автоматического определения MTU — лучше всех.


Статья-обновление моих прошлых проверок (2018 и 2019), на момент тестирования я использую Kubernetes 1.19 в Ubuntu 18.04 с обновленными CNI на август 2020 года.


Прежде чем погрузиться в метрики...


Что нового с апреля 2019?


  • Можно протестировать на собственном кластере: можно запускать тесты на собственном кластере с использованием нашего инструмента Kubernetes Network Benchmark: knb
  • Появились новые участники
  • Новые сценарии: текущие проверки запускают тесты производительности сети "Pod-to-Pod", также добавлен новый сценарий "Pod-to-Service", запускающий тесты, приближенные к реальным условиям. На практике ваш Pod с API работает с базой в виде сервиса, а не через Pod ip-адрес (конечно же мы проверяем и TCP и UDP для обоих сценариев).
  • Потребление ресурсов: каждый тест сейчас имеет собственное сравнение ресурсов
  • Удаление тестов приложений: мы больше не делаем тесты HTTP, FTP и SCP, поскольку наше плодотворное сотрудничество с сообществом и сопровождающими CNI обнаружило пробел между результатами iperf по TCP и результатами curl из-за задержки в запуске CNI (первые несколько секунд при запуске Pod, что не характерно в реальных условиях).
  • Открытый исходный код: все источники тестов (скрипты, настройки yml и исходные "сырые" данные) доступны здесь

Эталонный протокол тестирования


Протокол подробно описан здесь, обратите внимание, что эта статья посвящена Ubuntu 18.04 с ядром по умолчанию.


Выбор CNI для оценки


Это тестирование нацелено на сравнение CNI, настраиваемых одним файлом yaml (поэтому исключены все, устанавливаемые скриптами, типа VPP и прочих).


Выбранные нами CNI для сравнения:


  • Antrea v.0.9.1
  • Calico v3.16
  • Canal v3.16 (Flannel network + Calico Network Policies)
  • Cilium 1.8.2
  • Flannel 0.12.0
  • Kube-router latest (2020–08–25)
  • WeaveNet 2.7.0

Настройка MTU для CNI


В первую очередь проверяем влияние автоматического определения MTU на производительность TCP:



Влияние MTU на производительность TCP


Еще больший разрыв обнаруживается при использовании UDP:



Влияние MTU на производительность UDP


С учетом ОГРОМЕННОГО влияния на производительность, раскрытого в тестах, мы хотели бы отправить письмо-надежду всем сопровождающим CNI: пожалуйста, добавьте автоматическое определение MTU в CNI. Вы спасете котяток, единорожек и даже самого симпатичного: маленького девопсика.


Тем не менее если вам по-любому надо взять CNI без поддержки автоматического определения MTU — можно настроить его руками для получения производительности. Обратите внимание, что это относится к Calico, Canal и WeaveNet.



Моя маленькая просьба к сопровождающим CNI...


Тестирование CNI: необработанные данные


В этом разделе мы сравним CNI с правильным MTU (определенным автоматически, либо выставленным руками). Основная цель здесь — показать в виде графиков необработанные данные.


Цветовая легенда:


  • серый — образец (т.е. голое железо)
  • зеленый — пропускная способность выше 9500 мбит\с
  • желтый — пропускная способность выше 9000 мбит\с
  • оранжевый — пропускная способность выше 8000 мбит\с
  • красный — пропускная способность ниже 8000 мбит\с
  • синий — нейтральный (не связано с пропускной способностью)

Потребление ресурсов без нагрузки


В первую очередь — проверка потребления ресурсов, когда кластер "спит".



Потребление ресурсов без нагрузки


Pod-to-Pod


Этот сценарий подразумевает, что клиентский Pod подключается напрямую к серверному Pod по его ip-адресу.



Сценарий Pod-to-Pod


TCP


Результаты Pod-to-Pod TCP и соответствующее потребление ресурсов:




UDP


Результаты Pod-to-Pod UDP и соответствующее потребление ресурсов:




Pod-to-Service


Этот раздел актуален для реальных случаев использования, клиентский Pod соединяется с серверным Pod через сервис ClusterIP.



Сценарий Pod-to-Service


TCP


Результаты Pod-to-Service TCP и соответствующее потребление ресурсов:




UDP


Результаты Pod-to-Service UDP и соответствующее потребление ресурсов:




Поддержка политик сети


Среди всех вышеперечисленных, единственный, не поддерживающий политики, это Flannel. Все остальные правильно реализуют сетевые политики, включая входящие и исходящие. Отличная работа!


Шифрование CNI


Среди проверяемых CNI есть те, что могут шифровать обмен по сети между Pod:


  • Antrea с помощью IPsec
  • Calico с помощью wireguard
  • Cilium с помощью IPsec
  • WeaveNet с помощью IPsec

Пропускная способность


Поскольку осталось меньше CNI — сведем все сценарии в один график:



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


В этом разделе мы будет оценивать ресурсы, используемые при обработке связи Pod-to-Pod в TCP и UDP. Нету смысла рисовать график Pod-to-Service, поскольку он не дает дополнительной информации.




Сводим все вместе


Давайте попробуем повторить все графики, мы тут немного привнесли субъективности, заменяя фактические значения словами "vwry fast", "low" и т.п.



Заключение и мои выводы


Тут немножко субъективно, поскольку я передаю собственную интерпретацию результатов.


Я рад, что появились новые CNI, Antrea выступил неплохо, реализовано много функций даже в ранних версиях: автоматическое определение MTU, шифрование и простая установка.


Если сравнивать производительность — все CNI работают хорошо, кроме Kube-OVN и Kube-Router. Kube-Router также не смог определить MTU, я не нашел нигде в документации способа его настройки (тут открыт запрос на эту тему).


Что касается потребления ресурсов, то по-прежнему Cilium использует больше оперативной памяти, чем другие, но компания-производитель явно нацелена на крупные кластеры, что явно не то же самое, как тест на трехузловом кластере. Kube-OVN также потребляет много ресурсов процессорного времени и оперативной памяти, но это молодой CNI, основанный на Open vSwitch (как и Antrea, работающий лучше и с меньшим потреблением).


Сетевые политики есть у всех, кроме Flannel. Весьма вероятно, что он никогда не будет их поддерживать, поскольку цель проще пареной репы: чем легче, тем лучше.


Также кроме прочего, производительность шифрования настроящий восторг. Calico — один из старейших CNI, но шифрование было добавлено всего пару недель назад. Они выбрали wireguard вместо IPsec, и проще говоря, все работает великолепно и потрясно, полностью вытесняя другие CNI в этой части тестирования. Конечно же растет потребление ресурсов из-за шифрования, но достигаемая пропускная способность того стоит (Calico в тесте с шифрованием показал шестикратное превосходство по сравнению с Cilium, занимающим второе место). Больше того, можно включить wireguard в любое время после развертывания Calico в кластере, а также, если пожелаете, можете отключить его на короткое время или навсегда. Это невероятно удобно, но! Мы напоминаем, что Calico не умеет сейчас автоматически определять MTU (эта функция запланирована в следующих версиях), так что не забывайте настраивать MTU, если ваша сеть поддерживает Jumbo Frames (MTU 9000).


Кроме прочего, обратите внимание, что Cilium умеет шифровать трафик между узлами кластера (а не только между Pod), что может быть весьма актуально для публичных узлов кластера.


В качестве заключения я предлагаю следующие варианты использования:


  • Нужен CNI для сильно мелкого кластера, ИЛИ мне не нужна безопасность: работайте с Flannel, наиболее легким и стабильным CNI (он же один из старейших, его по легенде изобрел Homo Kubernautus или Homo Contaitorus). Также вас возможно заинтересует гениальнейший проект k3s, проверьте!
  • Нужен CNI для обычного кластера: Calico — ваш выбор, но не забывайте настроить MTU, если оно нужно. Легко и непринужденно можно играть с сетевыми политиками, включать и выключать шифрование и т.п.
  • Нужен CNI для (очень) крупномасштабного кластера: ну, тест не показывает поведение больших кластеров, я был бы рад провести тесты, но у нас нету сотен серверов с подключением 10гбит\с. Так что лучший вариант — запуск модифицированного теста на ваших узлах, хотябы с Calico и Cilium.