- PVSM.RU - https://www.pvsm.ru -
TL;DR: Все CNI работают как надо, за исключением Kube-Router и Kube-OVN, Calico за исключением автоматического определения MTU — лучше всех.
Статья-обновление моих прошлых проверок (2018 [1] и 2019 [2]), на момент тестирования я использую Kubernetes 1.19 в Ubuntu 18.04 с обновленными CNI на август 2020 года.
Протокол подробно описан здесь [7], обратите внимание, что эта статья посвящена Ubuntu 18.04 с ядром по умолчанию.
Это тестирование нацелено на сравнение CNI, настраиваемых одним файлом yaml (поэтому исключены все, устанавливаемые скриптами, типа VPP и прочих).
Выбранные нами CNI для сравнения:
В первую очередь проверяем влияние автоматического определения MTU на производительность TCP:
Влияние MTU на производительность TCP
Еще больший разрыв обнаруживается при использовании UDP:
Влияние MTU на производительность UDP
С учетом ОГРОМЕННОГО влияния на производительность, раскрытого в тестах, мы хотели бы отправить письмо-надежду всем сопровождающим CNI: пожалуйста, добавьте автоматическое определение MTU в CNI. Вы спасете котяток, единорожек и даже самого симпатичного: маленького девопсика.
Тем не менее если вам по-любому надо взять CNI без поддержки автоматического определения MTU — можно настроить его руками для получения производительности. Обратите внимание, что это относится к Calico, Canal и WeaveNet.
Моя маленькая просьба к сопровождающим CNI...
В этом разделе мы сравним CNI с правильным MTU (определенным автоматически, либо выставленным руками). Основная цель здесь — показать в виде графиков необработанные данные.
Цветовая легенда:
В первую очередь — проверка потребления ресурсов, когда кластер "спит".
Потребление ресурсов без нагрузки
Этот сценарий подразумевает, что клиентский Pod подключается напрямую к серверному Pod по его ip-адресу.
Сценарий Pod-to-Pod
TCP
Результаты Pod-to-Pod TCP и соответствующее потребление ресурсов:
UDP
Результаты Pod-to-Pod UDP и соответствующее потребление ресурсов:
Этот раздел актуален для реальных случаев использования, клиентский Pod соединяется с серверным Pod через сервис ClusterIP.
Сценарий Pod-to-Service
TCP
Результаты Pod-to-Service TCP и соответствующее потребление ресурсов:
UDP
Результаты Pod-to-Service UDP и соответствующее потребление ресурсов:
Среди всех вышеперечисленных, единственный, не поддерживающий политики, это Flannel. Все остальные правильно реализуют сетевые политики, включая входящие и исходящие. Отличная работа!
Среди проверяемых CNI есть те, что могут шифровать обмен по сети между Pod:
Поскольку осталось меньше CNI — сведем все сценарии в один график:
В этом разделе мы будет оценивать ресурсы, используемые при обработке связи Pod-to-Pod в TCP и UDP. Нету смысла рисовать график Pod-to-Service, поскольку он не дает дополнительной информации.
Давайте попробуем повторить все графики, мы тут немного привнесли субъективности, заменяя фактические значения словами "vwry fast", "low" и т.п.
Тут немножко субъективно, поскольку я передаю собственную интерпретацию результатов.
Я рад, что появились новые CNI, Antrea выступил неплохо, реализовано много функций даже в ранних версиях: автоматическое определение MTU, шифрование и простая установка.
Если сравнивать производительность — все CNI работают хорошо, кроме Kube-OVN и Kube-Router. Kube-Router также не смог определить MTU, я не нашел нигде в документации способа его настройки (тут [8] открыт запрос на эту тему).
Что касается потребления ресурсов, то по-прежнему 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), что может быть весьма актуально для публичных узлов кластера.
В качестве заключения я предлагаю следующие варианты использования:
Автор: Павел
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/blog-kompanii-southbridge/356899
Ссылки в тексте:
[1] 2018: https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-36475925a560
[2] 2019: https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-updated-april-2019-4a9886efe9c4
[3] knb: https://github.com/InfraBuilder/k8s-bench-suite
[4] Antrea: https://antrea.io/docs/master/getting-started/
[5] Kube-OVN: https://github.com/alauda/kube-ovn
[6] здесь: https://github.com/InfraBuilder/benchmark-k8s-cni-2020-08
[7] здесь: https://github.com/InfraBuilder/benchmark-k8s-cni-2020-08/blob/master/PROTOCOL.md
[8] тут: https://github.com/cloudnativelabs/kube-router/issues/165
[9] k3s: https://k3s.io/
[10] Источник: https://habr.com/ru/post/518782/?utm_source=habrahabr&utm_medium=rss&utm_campaign=518782
Нажмите здесь для печати.