Linkerd 2.20 вышел с заметным, а не декоративным апдейтом: проект обещает сократить потребление памяти control plane до 85% в сценариях с высоким churn pod’ов и добавить балансировку, которая учитывает rate limit. Для команд, живущих в Kubernetes, это не очередная полировка service mesh, а вполне практичный сигнал: сетевой слой пытаются сделать умнее и дешевле одновременно.
О релизе Linkerd 2.20 сообщает InfoQ. В новой версии сообщество Linkerd добавило rate-limit-aware load balancing, улучшило входящие метрики трафика и переработало destination controller, чтобы он заметно меньше ел память в моменты активного пересоздания и пересcheduling pod’ов. На фоне вечного спора «насколько service mesh вообще оправдывает свои накладные расходы» разработчики проекта бьют ровно в боль, которую платформенные команды хорошо знают по продакшену.
Главное изменение в релизе связано с маршрутизацией трафика. Классические механизмы балансировки обычно опираются на задержку и доступность endpoint’ов, но в реальной жизни сервис может быть технически доступен и при этом уже душить клиентов ограничениями по запросам. Linkerd теперь умеет распознавать HTTP-ответы, связанные с rate limit, и временно уводить часть нагрузки от endpoint’ов, которые начали троттлить трафик. Идея простая: не долбить перегруженный сервис до победного, а перераспределять запросы в сторону более здоровых инстансов. Особенно полезно это там, где микросервисы регулярно ходят во внешние API или во внутренние сервисы с динамическими лимитами.
Практический смысл здесь вполне приземлённый. Если mesh понимает, что сервис не упал, а именно ограничивает поток, у команды появляется шанс сохранить throughput и не раскрутить каскадную деградацию по всей цепочке вызовов. Для e-commerce, fintech и любых платформ с плотной сеткой внутренних API это куда интереснее, чем просто ещё один флажок в release notes. В распределённых системах перегрузка редко выглядит красиво: сначала растут retries, потом проседают очереди, затем вылезают латентности там, где их не ждали. Попытка встроить понимание rate limit прямо в плоскость данных выглядит как шаг в сторону более адекватного поведения инфраструктуры под реальной нагрузкой.
Вторая большая тема релиза — эффективность control plane. По данным проекта, переработка destination controller позволяет сократить использование памяти до 85% в условиях высокого churn pod’ов. Это важная оговорка: речь не про абстрактный «до 85% всегда и везде», а про конкретный проблемный сценарий, где Kubernetes-кластеры ведут себя особенно шумно. Для операторов это означает более рациональное расходование ресурсов: меньше памяти уходит на инфраструктурный слой, больше остаётся приложениям. Для небольших кластеров это вопрос выживания без лишнего вертикального масштабирования, для крупных инсталляций — способ не раздувать стоимость платформы только ради того, чтобы mesh не мешал жить остальным сервисам.
В этом месте Linkerd продолжает играть в свою давнюю стратегию. Проект, который развивает Buoyant и который написан на Rust, давно продаёт не максимализм по возможностям, а идею «достаточно мощный service mesh без лишней тяжести». На рынке, где Istio исторически ассоциируется с богатой экосистемой политик, сетевых сценариев и security-функций, Linkerd последовательно делает ставку на простоту эксплуатации, mTLS, базовое управление трафиком и наблюдаемость без обязательного инфраструктурного обвеса. Релиз 2.20 эту линию не ломает, а, скорее, дисциплинированно усиливает.
Отдельно в версии 2.20 обновили метрики входящего трафика. Для платформенных и SRE-команд это, возможно, не такой яркий пункт, как сокращение памяти, но в повседневной эксплуатации он не менее полезен. Чем точнее телеметрия на входе, тем проще ловить узкие места, разбирать всплески задержек и понимать, как сервис ведёт себя во время инцидента, а не после него в ретроспективе. Это укладывается в более широкий тренд cloud-native-инфраструктуры: наблюдаемость давно перестала быть приятным бонусом и стала частью базовой инженерной гигиены. InfoQ отдельно отмечает, что эти доработки продолжают инвестиции Linkerd в observability и логично дополняют прежние интеграции с OpenTelemetry.
Контекст у релиза тоже показательный. Рынок service mesh уже не живёт в режиме раннего хайпа, когда сам факт наличия retries, circuit breaking и mutual TLS продавался как почти обязательная зрелость платформы. Теперь эти возможности всё чаще воспринимаются как гигиенический минимум, а конкуренция смещается в сторону операционной пользы: сколько это стоит по ресурсам, насколько сложно поддерживать, как быстро команда поймёт, что именно пошло не так. Параллельно на архитектурные решения давят Kubernetes Gateway API и eBPF-подходы, которые тоже обещают упростить или переосмыслить сетевой слой. В такой обстановке Linkerd 2.20 выглядит как попытка доказать, что service mesh всё ещё имеет смысл, если он решает конкретные эксплуатационные проблемы, а не коллекционирует функции ради таблицы сравнений.
Для русскоязычных DevOps- и platform-команд вывод довольно прямой: Linkerd 2.20 не предлагает новую религию, зато предлагает более вменяемую экономику и более умное поведение трафика в неприятных сценариях. И дальше вопрос будет не в том, у кого длиннее список фич, а в том, какой сетевой слой лучше переживает динамичный Kubernetes без штрафа по сложности и ресурсам.