Comments 10
Да. Контрек дорого. Особенно, в ядре. Потому у нас и есть conntrackd. Но state — всё равно дорого и никуда вы от этого не денетесь.
Несмотря на слово «соединение», это всё касается и UDP тоже: привет приложениям, которые любят спрашивать «где myapp.tld» 500 раз в секунду или отправлять логи через GELF over UDP каждый раз с нового порта.
icmp тоже касается. Отключение контрека для высоконагруженных udp/icmp — это первое дело.
Не просто касается, а именно udp как раз и есть основная масса соединений, живущих до истечения таймаута. Соединения stateful протоколов грохаются сразу при обнаружении корректного закрытия соединения участниками, так что тот же tcp остаётся висеть только если никто не соизволил хотя бы FIN отправить. Что, само собой, вообще неправильно.
Поэтому странно читать про многогигабайтный conntrack, который никак не удавалось побороть. Ну перешли бы на tcp, благо memcached умеет.
Also постоянное упоминание Calico создаёт впечатление того, что это прямо его уникальная фича. На мой взгляд, можно было хотя бы вскользь упомянуть, что iptables/nftables тоже умеют conntrack для указанного трафика не задействовать.
Чего там в nftables с conntrack и как с ним работать? Ж) Ну и с nfset до кучи
запущенных на удаленных нодах, так что бы мы могли запускать очень большое количество соединений в секунду
"чтобы"
но do-not-track увеличила потребление CPU примерно на 20% :
При этом на иллюстрации мы видим снижение использования CPU
Когда Linux conntrack вам больше не товарищ