Test

Пользователь с Reddit под ником mathisweirdaf поделился интересными наблюдениями:

 $ ls -lh /usr/bin/{test,[}-rwxr-xr-x 1 root root 59K  Sep  5  2019 '/usr/bin/['-rwxr-xr-x 1 root root 55K  Sep  5  2019  /usr/bin/test

[ и test должны быть псевдонимами друг друга, и все же между исполняющими их файлами из GNU coreutils наблюдается разница в 4Кб. Почему?

Во-первых, для всех, кого это удивило: да, существует /usr/bin/[. По этой теме у меня есть отдельная статья (англ.), но я все же коротко поясню:

Когда вы пишите if [ -e /etc/passwd ]; then .. эта скобка выступает не синтаксисом оболочки, а просто стандартной командой с забавным именем. Обычно она встроена в оболочку, но иногда может реализовываться через /usr/bin/[. Это объясняет многое из ее загадочного поведения, например, почему она чувствительна к пробелам: [1=2] оказывается не более валидно, чем ls-l/tmp.

Тем не менее откуда возникает разница в размере? Можно сравнить вывод objdump, чтобы увидеть, куда помещаются данные. Вот выдержка из objdump -h /usr/bin/[:

              size                                          offset15 .text         00006e82  0000000000002640  0000000000002640  00002640  2**416 .fini         0000000d  00000000000094c4  00000000000094c4  000094c4  2**217 .rodata       00001e4c  000000000000a000  000000000000a000  0000a000  2**5

А вот objdump -h /usr/bin/test:

15 .text         000068a2  0000000000002640  0000000000002640  00002640  2**416 .fini         0000000d  0000000000008ee4  0000000000008ee4  00008ee4  2**217 .rodata       00001aec  0000000000009000  0000000000009000  00009000  2**5

Здесь мы видим, что сегмент .text (скомпилированный исполняемый код) на 1504 байта больше, в то время как .rodata (постоянные значения и строки) больше на 864 байта.

Суть в том, что увеличенный размер сегмента .text вынуждает его перемещаться из 8000 в 9000, пересекая границу размера страницы 0х1000 (4096) и, следовательно, смещая все другие сегменты на 4096 байтов. Именно эту разницу в размере мы и наблюдаем.

Единственное номинальное отличие между [ и test в том, что [ требует наличия ] в качестве заключительного аргумента. Проверка этого потребовала бы минимальное количество кода, так зачем все же используются те самые ~1500 байтов?

Поскольку сложно просматривать отделенные исполнительные файлы, я создал собственную копию coreutils и сравнил список функций в каждом:

$ diff -u <(nm -S --defined-only src/[ | cut -d ' ' -f 2-) <(nm -S --defined-only src/test | cut -d ' ' -f 2-)--- /dev/fd/63      2021-02-02 20:21:35.337942508 -0800+++ /dev/fd/62      2021-02-02 20:21:35.341942491 -0800@@ -37,7 +37,6 @@ D __dso_handle d _DYNAMIC D _edata-0000000000000099 T emit_bug_reporting_address B _end 0000000000000004 D exit_failure 0000000000000008 b file_name@@ -63,7 +62,7 @@ 0000000000000022 T locale_charset 0000000000000014 T __lstat 0000000000000014 t lstat-0000000000000188 T main+00000000000000d1 T main 000000000000000b T make_timespec 0000000000000004 d nslots 0000000000000022 t one_argument@@ -142,16 +141,10 @@ 0000000000000032 T umaxtostr 0000000000000013 t unary_advance 00000000000004e5 t unary_operator-00000000000003d2 T usage+0000000000000428 T usage 0000000000000d2d T vasnprintf 0000000000000013 T verror 00000000000000ae T verror_at_line-0000000000000008 D Version-00000000000000ab T version_etc-0000000000000018 T version_etc_ar-000000000000042b T version_etc_arn-000000000000002f R version_etc_copyright-000000000000007a T version_etc_va 000000000000001c r wide_null_string.2840 0000000000000078 T x2nrealloc 000000000000000e T x2realloc

Главные участники это функции version_etc*. Что они делают?

Давайте посмотрим:

/* The three functions below display the --version information the   standard way [...]

Это 260 строк развернутых, интернационализированных, условных способов форматирования данных, которые составляют вывод --version. Все вместе они занимают около bc <<< "ibase=16; 7A+2F+42B+18+AB+8+99" = 1592 байтов.

Что это значит? Все просто. Дополнительные 4Кб уходят вот на что:

$ /usr/bin/[ --version[ (GNU coreutils) 8.30Copyright (C) 2018 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.Written by Kevin Braunsdorf and Matthew Bradburn.

[ --version недостает заключительной ], поэтому вызов оказывается недействительным, и результат определяется реализацией. GNU спокойно позволяет вывести информацию о версии.

Тем временем /usr/bin/test --version оказывается действительным вызовом, и POSIX предписывает, чтобы она возвращала успех, когда первый параметр (--version) является не пустой строкой.

Эта разница даже упоминается в документации:

Примечание: [ отвечает за опции --help и --version, а test нет.test рассматривает каждую из них просто как непустую строку.

Загадка разгадана!

(Задачка: каковы будут последствия, если вопреки POSIX test будет поддерживать --help и --version?)

Перевод статьи подготовлен в преддверии старта курса Автоматизация тестирования на JavaScript

---

История, которая может показаться вам до боли знакомой:

Вы работаете QA в небольшой команде разработчиков; сегодня утро четверга второй недели вашего двухнедельного спринта. У вашей команды еще несколько историй (story) в разработке, которые должны быть утверждены к утру пятницы, чтобы быть готовыми к демонстрации днем. Ваши планы на вечер четверга начинают таять на ваших глазах.

На утреннем стендапе разработчики говорят, что они уже вот-вот заканчивают. Вы знаете, что они пишут модульные и компонентные тесты в рамках процесса разработки, и вы уже выполнили с ними несколько прогонов фич, так что вы уверены, что получите качественный код. Тем не менее, в дополнение к тестированию истории, вам все равно придется завершать автоматизацией UI и API, проверять некоторые нефункциональные требования и провести специфическое тестирование работоспособности И один день это не так много времени на все это. Вы, вероятно, можете уложиться в это время с тестированием, но успеть с автоматизацией будет нереально. Вы делитесь со скрам-мастером этими неприятными новостями.

ОК, говорит скрам мастер, как насчет, и вы точно знаете, что будет дальше. как насчет того, чтобы мы передвинули автоматизацию на следующий спринт? Автоматизация, стоящая непосредственно перед отметкой выполнено, заложенная в историю и всегда занимающая часть оцененного времени, выталкивается в будущее. В очередной раз. Мне это тоже не нравится, говорит ваш скрам-мастер, видя выражение вашего лица, но сейчас наша скорость на виду, это очень важно, поскольку мы приближаемся к этому гигантскому майлстоуну мы просто не можем не добить наши стори поинты.

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

Конец истории

Держу пари, что эта история, к сожалению, знакома многим из вас. Контекст или причина не имеют значения, мы неизбежно оказываемся в ситуациях, когда нас заставляют откладывать, сокращать или просто пропускать автоматизацию тестирования. К сожалению, важность автоматизации в Agile Delivery и последствия ее отсрочки уходят из виду многих правообладателей, специалистов по планированию, менеджеров и т. д. Для них автоматизация тестирования кажется требованием, которое в общем неплохо было бы иметь, но которым можно пренебречь, когда поджимают дедлайны.

Я оказался именно в такой ситуации и обнаружил, что фраза регрессионная спираль смерти является хорошим иллюстрированием нескольких концепций тестирования и полезна для информирования правообладателей о рисках неадекватной автоматизации тестирования. Если вам приходится постоянно отстаивать необходимость полной автоматизации тестирования в своих Agile-командах, добавьте ее в свой арсенал, и, надеюсь, вы добьетесь такого же успеха на этом поприще, как и я.

Регрессионное тестирование

Прежде чем мы перейдем к регрессионной спирали смерти, мы должны понять идею регрессионного тестирования, и в частности, что тестирование фичи это больше, чем просто тестирование фичи.

Программное обеспечение это по сути строки кода, написанные в разное время разными людьми. Иногда код пишется годами людьми, которые никогда не встретятся. И весь этот код должен работать вместе. Это непростая задача, и разработчики программного обеспечения разработали стратегии, подходы, шаблоны и методы, чтобы сделать процесс создания сложных систем немного проще, менее рискованным и более предсказуемым. Эти стратегии помогают гарантировать, что изменения, сделанные здесь в программном обеспечении, будут иметь ожидаемые эффекты именно здесь, и не будут иметь неожиданных последствий в других местах.

К сожалению, независимо от того, насколько мы осторожны при реализации нового кода, всегда есть вероятность, что изменения приведут к непредвиденным побочным эффектам, что код для нашей новой фичи каким-то образом повлияет на старый функционал в соседних или даже совершенно не связанных областях системы. Учитывая, как программный код переплетается и взаимосвязывается, так как новые фичи накладываются на предыдущие новыми людьми или новыми командами, вероятность непредвиденных побочных эффектов может быть любой, от в принципе возможной до вполне ожидаемой.

Изменения, которые нарушают ранее работающий код, называются регрессиями, и существует целая категория тестирования, посвященная обнаружению этих типов дефектов: регрессионное тестирование. Регрессионное тестирование не более чем подтверждение того, что вещи, которые работали раньше, все еще работают, что новый код не имеет непредвиденных побочных эффектов в других областях приложения.

Таким образом, наивно рассматривать тестирование как просто тестирование исключительно новой фичи. Тестирование функционала требует значительного объема тестирования снаружи и вокруг него в связанных или просто областях приложения с высоким риском и все это потому, что мы должны предполагать, что могут возникнуть непреднамеренные побочные эффекты.

Правообладатели или люди, не имеющие опыта разработки, часто упускают риск внесения критических изменений за пределами функции в разработке и необходимости регрессионного тестирования. Я даже слышал, как говорят, что тестирование функции это просто проверка перечисленных критериев приемлемости этой функции(!!!). К сожалению, игнорирование или недооценка реальной цены регрессии является ключевым фактором для входа в регрессионную спираль смерти.

Agile Delivery и бремя регрессии

Agile Delivery вводит две концепции, относящиеся к регрессионной спирали смерти. Во-первых, Agile Delivery делит фичи на небольшие, отдельные пользовательские истории (user stories). Каждая пользовательская история должна быть атомарной, чтобы ее можно было разрабатывать и тестировать как отдельный объект. Во-вторых, Agile Delivery способствует коротким циклам разработки с небольшими итеративными релизами. Все виды и гибриды Agile, Scrum, Kanban, SAFE, LeSS, ScrumBan и т. д. по-своему используют эти концепции. Давайте посмотрим на каждую в отдельности.

Agile Delivery отходит от использования больших функций, определенных (даже более крупными) документами спецификаций, к пользовательским историям, каждая из которых представляет собой небольшую часть общего объема работ. Истории Agile независимо разрабатываются, тестируются, ревьюятся и утверждаются.

Использование небольших отдельных историй может создать ложное чувство изоляции между изменениями кода в разных историях, подрывая при этом регрессионное тестирование. Да, пользовательские истории независимы, но под этими историями находится тот же взаимосвязанный код и тот же риск внесения непреднамеренных изменений. Неважно, насколько четко вы разделяете свои истории или насколько хорошо вы определяете критерии приемлемости, регрессионное тестирование так же необходимо в Agile-разработке, как и при разработке одной большой функции в каскадном процессе.

История 13 была внедрена и протестирована. Нам не о чем беспокоиться?
/ НЕТ! Изменения в коде могли повлиять на другие истории (как связанные, так и не связанные с этой историей)

Это ключевой момент, необходимый для понимания регрессионной спирали смерти: изменения в одной истории или добавление новой истории всё еще могут негативно влиять на поведение любой другой истории. Переход к небольшим, отдельным историям помогает нам определять, понимать и распараллеливать работу, но это никоим образом не гарантирует изоляцию и не предотвращает воздействие одной истории на другую. Необходимость регрессионного тестирования для выявления этих воздействий не изменилась.

Давайте перейдем ко второй концепции что Agile Delivery поощряет небольшую, инкрементную доставку. Если бы необходимо было регрессировать приложение каждые шесть месяцев, стоимость регрессионного тестирования, даже медленного ручного, не была бы ощутимой. Фактически, именно так мы раньше и поставляли программное обеспечение до перехода к Agile разработке у нас был бы план регрессионного тестирования, и каждые шесть месяцев мы выполняли этот план перед релизом. Это часто занимало дни или недели, но в рамках шестимесячного цикла релиза это было не слишком обременительно.

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

Давайте рассмотрим простой гипотетический набор спринтов, чтобы прояснить, насколько быстро стоимость регрессии может отягощать скорость команды.

Предположим, у нас есть недавно созданная Agile-команда, которая только начинает свою первую итерацию разработки (спринт). На первой итерации (или некоторой начальной продолжительности в потоковой модели) у нас может быть три истории для тестирования. Тестирование этих историй довольно простое мы просто тестируем эти три истории. Во второй итерации мы добавляем две дополнительные истории. Сколько усилий будет затрачено на тестирование этих историй? Наивный ответ несколько меньше усилий, чем для первого спринта, так как мы тестируем только две истории. Однако, основываясь на нашем понимании того, что изменения кода могут вызвать регрессию в любой области приложения, мы знаем, что мы должны протестировать обе новые истории, а также регрессировать три ранее завершенные истории.

Таким образом, наши реальные усилия по тестированию во второй итерации фактически больше, чем в первой, несмотря на то, что мы взяли на одну историю меньше.

Очевидно, что это слишком упрощенная модель, поскольку она предполагает, что усилия, необходимые для регрессии ранее завершенной истории, эквивалентны проверке новой истории. Конечно, не все должно быть полностью регрессировано, и тестировать что-либо всегда легче во второй раз. Однако стоимость регрессии не равна нулю, и для сложного программного обеспечения она может приближаться к первоначальной стоимости тестирования. Точное отношение первоначального тестирования к регрессионному тестированию не меняет того факта, что значительное количество времени на второй итерации будет потрачено на регрессию историй, завершенных на первой итерации, мы не можем просто полагаться на то, что они все еще будут работать.

Если мы экстраполируем этот шаблон на множество спринтов, мы увидим, что в модели Agile-разработки с ручной регрессией стоимость регрессии ранее завершенных историй быстро затмевает стоимость тестирования новых историй количество ранее завершенных историй накапливается в каждом спринте, и весь набор должен быть регрессирован на каждой итерации.

Это фундаментальная задача тестирования в Agile методологии инкрементный, итеративный характер процесса требует огромного количества регрессионного тестирования на каждой итерации, поскольку новые функции и истории добавляются в систему гораздо быстрее, за несколько дней или недель, а не месяцев или лет. Каждый раз, когда история завершена, она не только должна быть проверена, но и все ранее завершенные истории должны, в некоторой степени, быть проверены повторно. Ручная регрессия не может масштабироваться с увеличенной скоростью доставки Agile.

Это регрессионная спираль смерти с каждой итерацией все сложнее и сложнее адекватно регрессировать существующее приложение. Производительность команды схлопывается, так как бремя тестирования предыдущей работы занимает все большую и большую часть общего объема усилий. Оставленная без контроля, начальная скорость команды замедлится, а затем остановится, так как каждое новое изменение требует существенного и постоянно растущего набора предыдущих историй, которые также должны быть проверены.

Автоматизация в Agile Delivery

В предыдущем разделе мы предполагали, что каждый тест был ручным, а стоимость повторного запуска теста составляла некоторую часть первоначальных усилий. К счастью, мы знаем, что это не так мы знаем, что можем использовать программное обеспечение для автоматической проверки ранее выполненных тестов с помощью, как вы уже догадались, автоматизации тестирования!

Автоматизация тестирования существует во многих формах модульные тесты, API-тесты, тесты компонентов, интеграционные тесты, тесты E2E, визуальные регрессионные тесты пользовательского интерфейса и т. д. Неважно, кто их пишет или как они взаимодействуют с приложением, все автоматизированные тесты помогают проверить существующую функциональность и обеспечить уверенность в том, что предыдущая работа не была нарушена, что значительно снижает бремя ручной регрессии.

Важно понимать, что автоматизация тестирования не ускоряет первоначальное тестирование. На самом деле, внедрение автоматизации тестирования часто замедляет базовую скорость разработки. Автоматизация это процесс разработки, который требует продумывания и опыта, как и всё остальное! Автоматизация не тестирует это просто запрограммированная проверка того, что уже было протестировано. К счастью, это именно то, что нам нужно для смягчения регрессионной спирали смерти!

Если учесть моменты двух предыдущих разделов то, что изменения в программном обеспечении могут иметь непреднамеренные последствия, и что agile delivery это просто непрерывный поток небольших изменений становится очевидным, что agile delivery не может функционировать без автоматизации тестирования. Попытка итеративной доставки без него это все равно, что отправиться в дальнюю дорогу, но отказаться от остановок, потому что остановки замедляют вас. Топливо фундаментальная часть автомобильного путешествия (на данный момент), так же, как автоматизация тестирования фундаментальная часть Agile Delivery. Автоматизация это единственное, что может смягчить удушающее бремя регрессии и избежать резкого падения скорости разработки.

Зачастую правообладатели или менеджеры утверждают, что автоматизацию тестирования следует полностью игнорировать, перенаправив 100% усилий по тестированию будущих спринтов на ручную регрессию. Гораздо чаще команды вынуждены принимать истории с частичной или достаточно хорошей автоматизацией. Выполнение этого требования все еще передает некоторый процент от общей стоимости регрессии в будущие спринты на ручное неавтоматическое тестирование. К сожалению, любая незаконченная автоматизация, независимо от того, насколько она мала, обязательно увеличивает нагрузку регрессии в будущих спринтах.

Оставляя любое количество регрессии на трудоемкое, ручное тестирование, вы встаете на скользкую дорожку, которая может быстро привести к регрессионной спирали смерти. Если вы тестируете и автоматизируете историю, что произойдет, если из-за нехватки времени мы согласимся с правообладателем и признаем историю законченной с неполной автоматизацией? Некоторое количество бремени регрессии передается на следующую итерацию, которая затем потребляет даже больше времени на тестирование в последующем спринте. Это дает еще меньше времени для автоматизации в этой итерации, в результате чего автоматизируется еще меньше тестов, еще больше спихивая ее в будущее и т. д. Этот шаблон повторяется из итерации в итерацию, создавая цикл положительной обратной связи, пока у QA совсем не останется времени на автоматизацию, из-за долгих часов и вечеров, едва удовлетворяющих потребность в ручном тестировании, результирующих в уходе с работы и поиске компании с более зрелой agile практикой.

Я твердо убежден в том, что без полной автоматизации тестирования не может быть здоровой Agile Delivery. Полная автоматизация историй с набором средств автоматизации, охватывающим все виды тестов (модуль, компонент, интеграция, пользовательский интерфейс и т. д.), абсолютно необходима для поддержания скорости доставки на протяжении всего жизненного цикла. Любое предложение о послаблении этого требования для каждой истории следует отвергать и объяснять, что это такое краткосрочное отвлечение для создания восприятия успеха, в то же время ставящее под угрозу долгосрочные цели развития. Не говоря уже о здравом уме.

Спираль смерти

Вернемся к нашей маленькой истории.

Утро четверга перед демонстрационным днем, и у вашей команды в разработке еще несколько историй. Разработчики заканчивают, и код должен быть готов к тестированию очень скоро. Тем не менее, осталось не так много времени. Правообладатель, услышав эту плохую новость, созывает экстренное собрание и предлагает отложить автоматизацию тестирования, чтобы гарантировать, что команда выполнит свои обязательства по спринту.

Вы собираетесь протестовать, когда ваш скрам-мастер вмешивается: Мы не можем этого сделать! Это первый шаг к регрессионной спирали смерти!

Автоматизация всегда является частью определения готовности, добавляет разработчик, это часть продукта, как код, ориентированный на клиента.

Вы хотите, чтобы мы преуспели или просто казались преуспевающими? Эти слова вашего бизнес-аналитика, вызывает улыбку на вашем лице.

Вы решаете отменить собеседование на следующей неделе.

Слова благодарности

Я не изобрел термин регрессионная спираль смерти, но никогда не видел его в письменной форме. Самое раннее использование термина, которое я могу найти, находится в Тестировании экстремального программирования (2002) Лизы Криспин и Тип Хаус.

Несколько других ссылок можно найти с помощью быстрого поиска в Google:

http://ivory.idyll.org/blog/software-quality-death-spiral.html (2008)

https://xebia.com/blog/regression-testing-with-an-agile-mindset (2010)

---

Узнать всё о курсе Автоматизация тестирования на JavaScript

---

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

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

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

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

• Можно протестировать на собственном кластере: можно запускать тесты на собственном кластере с использованием нашего инструмента Kubernetes Network Benchmark: knb
• Появились новые участники
  
  • Antrea от VMware Tanzu
  • Kube-OVN от alauda.io
• Новые сценарии: текущие проверки запускают тесты производительности сети "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 (20200825)
• 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.