Сколько процессора и памяти съедает service mesh на кластере из 50 сервисов

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

Откуда вообще берутся накладные расходы

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

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

Что показывают реальные цифры по памяти

Числа говорят сами за себя. Лёгкий прокси на Rust типично занимает около десяти-двадцати мегабайт памяти на под при очень низком потреблении процессора. Прокси на базе тяжёлого универсального движка стартует с сорока-пятидесяти мегабайт и может вырасти до ста и более, в зависимости от числа сервисов и сложности конфигурации.

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

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

Почему задержка тоже разная

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

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

Что изменил режим без прослоек

И вот ключевой поворот, без которого любое сравнение устарело. Если читать сравнение этих решений, написанное до середины 2025 года, оно почти наверняка игнорирует новый режим без прослоек, а это крупнейший сдвиг в мире service mesh с тех пор, как появился лёгкий прокси на Rust.

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

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

Где у режима без прослоек скрытая цена

Но честность требует показать и обратную сторону, иначе картина выходит однобокой. Служба на узле для четвёртого уровня действительно потребляет меньше всех компонентов плоскости данных. Но важно помнить, что она ограничена четвёртым уровнем и не делает тяжёлую работу седьмого уровня. Как только нагрузке нужен седьмой уровень, добавляется отдельный прокси на тяжёлом движке.

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

Чем различаются операционная сложность и набор возможностей

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

Это видно по конфигурации. У тяжёлого меша множество настроечных ресурсов: правила маршрутизации, политики назначения, фильтры, политики авторизации и аутентификации, и понимание того, как они все взаимодействуют, требует времени. Лёгкий меш следует принципу соглашения вместо настройки: ресурсов меньше, меньше возможностей ошибиться, но и меньше простора для тонкой настройки. Для команд, новых в service mesh, лёгкий вариант обычно быстрее выводит на продуктивность. Для команд, которым нужны продвинутое управление трафиком или сложная безопасность, вложение в освоение тяжёлого меша окупается.

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

Как посчитать выбор под кластер из 50 сервисов

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

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

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

Какой вывод следует из всего этого

Накладные расходы service mesh реальны и измеримы, и на кластере из пятидесяти сервисов выбор архитектуры выливается в ощутимую разницу по памяти, процессору и задержке. Лёгкий меш на специализированном прокси Rust исторически потребляет в разы меньше ресурсов и добавляет меньшую задержку, оставаясь при этом проще в освоении и безопасным по умолчанию. Тяжёлый меш предлагает несравнимо больше возможностей ценой сложности и аппетита, а его новый режим без прослоек серьёзно подтянул ресурсную сторону для четвёртоуровневых нагрузок, хотя на седьмом уровне его преимущество тает.

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