Отслеживание соединений (“conntrack”) является основной функцией сетевого стека ядра Linux. Она позволяет ядру отслеживать все логические сетевые соединения или потоки и тем самым идентифицировать все пакеты, которые составляют каждый поток, чтобы их можно было последовательно обрабатывать вместе. Conntrack — это важная функция ядра, которая используется в некоторых основных случаях: Кроме того, conntrack обычно повышает производительность системы (снижая потребление процессорного времени и время задержек пакетов), поскольку только первый пакет в потоке
должен пройти полную обработку стека сети, чтобы определить, что с ним делать. Смотрите пост «Сравнение режимов kube-proxy», чтобы увидеть пример того, как это работает. Тем не менее, у conntrack есть свои ограничения... Таблица conntrack имеет настраиваемый максимальный размер, и, если она заполняется, соединения обычно начинают отклоняться или прерываться. Для обработки трафика большинства приложений в таблице достаточно свободного места, и это никогда не превратится в проблему. Тем не менее, есть несколько сценариев, при которых стоит задуматься об использовании таблицы conntrack: Есть несколько нишевых типов приложений, попадающих в эти категории. Кроме того, если у вас много недоброжелателей, то заполнение таблицы conntrack вашего сервера множеством полуоткрытых соединений может использоваться в рамках атаки типа «отказ в обслуживании» (DOS). В обоих случаях conntrack может стать ограничивающим узким местом в вашей системе. В некоторых случаях настройки параметров таблицы conntrack может быть достаточно для удовлетворения ваших потребностей — путем увеличения размера или сокращения тайм-аутов conntrack (но если вы сделаете это неправильно, то столкнетесь с большими трудностями). Для других случаев будет необходимо обойти conntrack для агрессивного трафика. Приведем конкретный пример: один крупный SaaS провайдер с которым мы работали имел ряд memcached-серверов на хостах (не виртуальных машинах), каждый из которых обрабатывал 50К+ кратковременных соединений в секунду. Они экспериментировали с конфигурацией conntrack, увеличивали размеры таблиц и сокращали время отслеживания, но конфигурация была ненадежной, значительно увеличилось потребление ОЗУ, что было проблемой(порядка ГБайтов!), а соединения были настолько короткими что conntrack не создавал своего обычного выигрыша в производительности (уменьшение потребления ЦП или задержек пакетов). В качестве альтернативы они обратились к Calico. Сетевые политики Calico позволяют не использовать conntrack для определенного вида трафика (используя для политик опцию doNotTrack). Это обеспечило им необходимый уровень производительности плюс дополнительный уровень безопасности, предоставляемый Calico. Мы проводили тест на одном pod'е с memcached-сервером и множеством pod'ов memcached-клиентов, запущенных на удаленных нодах, так что бы мы могли запускать очень большое количество соединений в секунду. Сервер с pod'ом memcached-сервера имел 8 ядер и 512k записей в conntrack таблице (стандартно настроенный размер таблицы для хоста).
Мы измеряли разницу в производительности между: без сетевой политики; с обычной Calico политикой; и Calico do-not-track политикой. Для первого теста мы задали количество коннектов до 4.000 в секунду, поэтому мы могли сфокусироваться на разнице потребления CPU. Здесь не было существенных отличий между отсутствием политики и обычной политики, но do-not-track увеличила потребление CPU примерно на 20% : Во втором тесте мы запустили столько соединений, сколько могли сгенерировать наши клиенты и измеряли максимальное количество соединений в секунду, которое мог отработать наш memcached-сервер. Как и ожидалось, в случае “без политик” и “обычная политика” оба достигли лимита conntrack в более чем 4,000 соединений в секунду (512k / 120s = 4,369 соединений/с). С do-not-track политикой наши клиенты отправляли 60,000 соединений в секунду без каких-либо проблем. Мы уверены, что могли бы увеличить это число, подключив большее количество клиентов, но чувствуем, что этих цифр уже достаточно, чтобы проиллюстрировать посыл этой статьи! Conntrack — это важная функция ядра. Он отлично выполняет свою работу. Зачастую его используют ключевые компоненты системы. Однако, в некоторых определенных сценариях, перегрузка из-за conntrack перевешивает обычные преимущества, которые он дает. В данном сценарии сетевые политики Calico могут быть использованы, чтобы выборочно отключать использование conntrack при этом повышая уровень сетевой безопасности. Для всего остального трафика conntrack продолжает быть вашим товарищем! Системный администратор Linux, @violin_admin