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

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

Представьте, однажды вы приходите в новую компанию на позицию Automation QA и перед вами возникает задача: на пустом поле проекта посеять зерна автотестов, которые прорастут в регулярный процесс тестирования и будут отлавливать различные баги. Такая задача возникла и передо мной, поэтому я хочу поделиться своим опытом, как строил тестирование кастомного K8s CNI-плагина в новой для себя области. Статья будет полезна QA-инженерам, которые на «ты» с Python, но на «вы» с тестированием Kubernetes с помощью автотестов. При решении задачи я столкнулся с вопросами, на которые нигде не нашел ответа. Возможно, раз мне помог описанный путь, поможет и вам.