Сеть контейнеров под нагрузкой: что измерять и оптимизировать

Если запросы между контейнерами стали медленнее, увеличение лимитов CPU не обязательно поможет: задержку могут добавлять DNS, сетевой оверлей, правила kube-proxy или перегруженный узел. В Kubernetes 1.32 разбирать проблему стоит по слоям — от приложения и Service до сетевого интерфейса ноды. Универсальных цифр «нормальной сети» нет: ниже — план измерений, который покажет, где именно теряются миллисекунды, и поможет оценить эффект оптимизации без выдуманных бенчмарков.

Сначала зафиксируйте условия измерения

Сравнивать результаты можно только при неизменных условиях. Запишите версию Kubernetes и CNI-плагина, тип облака или серверов, число узлов и подов, размер запроса, протокол, параллельность и расположение клиента с сервером. Для каждого теста отметьте, идут ли поды на одной ноде или на разных: межузловой трафик обычно проходит другой путь.

Нужны три точки сравнения: клиент обращается к процессу напрямую по адресу пода, через Kubernetes Service и, если это часть рабочей схемы, через внешний балансировщик. Разница между ними укажет, на каком участке искать добавочную задержку. Не меняйте одновременно CNI, режим kube-proxy и размер узлов — после такого эксперимента нельзя понять, что именно повлияло на результат.

• Измеряйте не только среднее время ответа, но и p50, p95 и p99: хвост задержек может ухудшаться, пока среднее выглядит стабильным.
• Записывайте пропускную способность, число ошибок и повторных передач TCP.
• Следите за CPU, памятью и сетевой нагрузкой на ноде во время теста.
• Повторяйте тест несколько раз и сравнивайте одинаковые интервалы нагрузки.

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

Разделите сетевой путь на участки

Проверьте приложение и адрес пода

Начните с запроса к поду в обход Service. Если уже здесь велики p95 и p99, сетевые правила Kubernetes могут быть ни при чём: проверьте время обработки запроса, очередь соединений, CPU throttling и доступность зависимостей. Сравните запросы между подами на одной ноде и на разных. Если разница появляется только между нодами, подозрение смещается к сетевому пути и физической сети.

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

Сравните запрос к Service и к поду

Service — логическая точка доступа, а не отдельный процесс, который принимает каждый запрос. Реализация перенаправления зависит от сетевых компонентов кластера и их конфигурации. Сравните время обращения к адресу пода и к Service при одинаковом числе запросов. Если разрыв заметен, проверьте состояние kube-proxy или заменяющего его компонента, а также распределение конечных адресов.

Не делайте вывод по одному короткому прогону: на результат влияют прогрев соединений, кеш DNS, повторное использование TCP-соединения и расположение подов. Отдельно проверьте новый запрос и серию запросов по уже установленному соединению.

Проверьте DNS отдельно от передачи данных

Прикладной тест часто включает разрешение имени, установление соединения и обработку ответа. Если всё измерять одной цифрой, задержку DNS легко принять за медленную сеть. Сравните время запроса по имени Service и по его IP в тестовой среде; затем посмотрите на частоту DNS-запросов и ошибки разрешения. Если приложение часто повторяет запросы к одному имени, проверьте настройки кеширования на стороне приложения и соответствие их поведения принятой архитектуре.

Что сравнивать и чем платить

Таблица помогает локализовать участок, но не доказывает причину: например, рост повторных передач TCP может указывать на потери, однако сам по себе не устанавливает, где они возникли.

Оптимизация сети начинается не с выбора «самого быстрого CNI», а с вопроса: на каком участке и при каких условиях появляется измеримая потеря?

Что оптимизировать после диагностики

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

Сравнение CNI или режимов обработки трафика имеет смысл только на одинаковом стенде и с одинаковой нагрузкой. Ускорение в одном синтетическом тесте может сопровождаться более высокой нагрузкой CPU, иной сложностью эксплуатации или несовместимостью с нужными сетевыми политиками. До смены реализации зафиксируйте функциональные требования: сетевые политики, шифрование, наблюдаемость, поддерживаемые ядра и порядок обновления.

После изменения повторите исходный тест и сопоставьте не одну цифру, а набор показателей: p95/p99, ошибки, пропускную способность и CPU на узле. Укажите размер выборки и длительность прогона. Если показатели колеблются, повторите измерение в нескольких сопоставимых интервалах; без этого небольшую разницу нельзя уверенно приписать настройке.

Граничные случаи: где тест обманывает

• Короткий прогон. Он может не захватить прогрев кешей, всплеск нагрузки или периодическое обслуживание. Увеличьте длительность и сохраните временной ряд, а не только итоговое среднее.
• Смешение DNS и сети. Запрос по имени включает разрешение имени, если приложение не использует уже полученный адрес. Разделяйте эти этапы.
• Один узел. Такой тест не показывает поведение межузлового пути. Зафиксируйте размещение подов и проведите отдельное сравнение.
• Слишком крупные пакеты или ответы. Результат для одного размера сообщения не описывает мелкие RPC-вызовы. Используйте размеры, характерные для реального трафика.
• Нагрузка только на тестовую сеть. Изолированный стенд может не воспроизводить конкуренцию за интерфейс, CPU и пропускную способность в рабочем кластере.

Термин: CNI — Container Network Interface, стандарт взаимодействия Kubernetes с сетевым плагином, который подключает поды к сети и настраивает их сетевую связность.

Что делать дальше

Сохраните исходные условия теста и постройте базовый профиль для четырёх путей: внутри одной ноды, между нодами, через Service и через DNS-имя. Затем выберите один участок с подтверждённым отклонением и проверьте одну гипотезу. После изменения продолжайте смотреть p95/p99, ошибки и загрузку сетевого интерфейса: именно эти показатели покажут, улучшилась ли сеть для реального трафика, а не только для одного удачного прогона.

Инвалидация DNS-кеша и настройка конкретного CNI зависят от выбранных компонентов; здесь разбирается метод измерения, а не конфигурация отдельного плагина.