Всем привет!

На связи Георг Гаал. Сегодня хочу поделиться своими мыслями о том, стоит ли — и почему стоит — внедрять Service mesh в современной инфраструктуре.

Эволюция инфраструктуры: от Docker до Kubernetes

В процессе развития продукта любая компания рано или поздно выходит на более высокий уровень зрелости. Сначала достаточно одного сервера с Docker и деплоя через GitLab Runner с docker-compose.yml. Но со временем появляются новые требования: отказоустойчивость, рост количества сервисов, необходимость масштабирования.

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

На этом этапе инженерный отдел эволюционно приходит к нескольким серверам. А ими нужно управлять. Раньше это удобно делалось через Ansible или SaltStack, но всё чаще и проще — взять Kubernetes, как on-prem, так и облачный.

Неважно, управляет ли он bare-metal-нодами или используется управляемый Kubernetes вроде GKE, EKS, AKS либо решения от отечественных провайдеров: Яндекса, Selectel или Таймвеба. Важно другое: это стандарт. Решение, проверенное временем. То, что позволяет разработчикам, DevOps-инженерам и SRE говорить на одном языке.

Кстати, скоро стартует новый поток курса «Kubernetes: Мега» от коллег из Слёрма.
Это мощная прокачка, особенно если хотите быстро выйти на продакшн-уровень.
Я сам учился иначе — смотрел ролики на YouTube, особенно у Дмитрия Столярова, и много экспериментировал сам. Тогда просто не было такого полноценного курса на русском языке, как сейчас.

Kubernetes: зрелость без комфорта

Допустим, мы уже развернули кластер Kubernetes, научились доставлять в него приложения — всё более-менее работает. Но начинаются боли из разряда «пятьсотые при деплое» или «что-то упало, но где — непонятно».

Типичные проблемы:

• при деплое на пару секунд пропадает доступ к сервису (а этого достаточно, чтобы клиенты ушли);

• новая версия одного сервиса ломает что-то в другой части системы;

• много времени уходит на разбор инцидентов, логи разрознены, мониторинг фрагментирован;

• забыли прописать readiness/liveness пробы — сервис мёртв, но считается здоровым;

• непонятно, где какие ресурсы выделены — и кто у кого что «съедает» (requests, limits и прочее).

А чем больше сервисов — тем больше сложностей с их взаимодействием. Всё это подталкивает к следующему этапу зрелости — Service mesh.

Зачем нужен Service mesh

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

• почему сервис A не достучался до B?

• почему у C выросла латентность?

• кто виноват — мы или внешний API?

• можно ли включить TLS для всего трафика — без боли?

• можно ли делать канареечные релизы на уровне сети?

Ответ на всё это — Service mesh. Но не как хайп или модная фича, а как инфраструктурная неизбежность.

Особенно болезненной становится ситуация, когда сервисы пишутся на разных технологиях. Например: бэкенд — на Java, фронт — на Node.js, а аналитика с внутренним порталом — на Python. Если бы стек был единым, часть проблем можно было бы решить библиотеками. Но в условиях разношёрстности нужна точка схождения, в которой можно управлять трафиком, перехватывать его, изменять. Этой точкой становится Service mesh.

Что такое Service mesh

Service mesh — это инфраструктурный слой, который управляет сетевыми взаимодействиями между сервисами. Обычно реализуется через сайдкары (отдельный прокси-контейнер рядом с каждым подом), например, на базе Envoy.

Среди популярных решений: Istio, Linkerd, Kuma, Consul Connect, Traefik mesh, NGINX Service mesh и др.

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

• Большое потребление ресурсов: каждый сайдкар должен понимать всю топологию. Это устраняется правильной настройкой меша.

• Новый режим работы без сайдкаров — Ambient mesh, где трафик обрабатывается специальным агентом на каждом узле. Это серьёзный шаг вперёд.

Что даёт Service mesh

1. Прозрачная телеметрия
Метрики, трейсинг, логирование сетевых запросов — без изменений в коде.
В моей практике был кейс: многокомпонентное приложение, разработанное ушедшей командой, внезапно начало тормозить. Только карта сети в Service mesh позволила найти внешний сервис, про который никто не знал. Убрали обращения, задеплоили фикс — и всё заработало. Без Service mesh это заняло бы в разы больше времени.

2. Безопасность и Zero Trust
Никакой сервис не может общаться с другим просто так — только по чётко заданной политике. Безопасники оценят.

3. Канареечные и A/B-релизы
Можно направлять, скажем, 10% трафика на новую версию сервиса, анализировать метрики и только потом переключать весь трафик. Разработка будет благодарна.

4. TLS — везде
Шифрование всего межсервисного трафика — автоматически, без боли. Выпуск и ротация сертификатов тоже на стороне Service mesh.

5. Централизованные политики доступа
Говорим: сервис foo может общаться только с bar.
Всё. Никаких iptables, CNI и нюансов плагинов. Все политики — в виде YAML-манифестов, лежат в Git. Полный аудит возможен.

Что не даёт Service mesh

Важно понимать, чего Service mesh не делает:

• не исправляет плохую архитектуру;

• не заменяет CI/CD;

• не спасает от плохих практик деплоя;

• не заменяет ingress или API Gateway (но может их дополнять).

Service mesh — не магическая палочка, и он сам по себе требует ресурсов: CPU, память, чуть увеличивает задержку. Но при росте сложности инфраструктуры — это плата за контроль и масштабирование.

Когда внедрять?

Правильный ответ — не слишком рано, но и не слишком поздно.

Если у вас 2–3 сервиса и всё стабильно — Service mesh, скорее всего, будет избыточен.
Если уже больше 5–6, и пошли проблемы со связностью, авторизацией, мониторингом — он реально экономит время и нервы.

Можно начать с лёгкого решения — например, Linkerd, а позже перейти на Istio. Или сразу брать Istio как наиболее популярное и гибкое.

Важно: Service mesh — модульная архитектура. Не нужно включать сразу всё. Начните с базового функционала, добавляйте остальное по мере роста зрелости команды и инфраструктуры.

Заключение

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

Да, придётся вникнуть. Да, нужно будет приручить Istio или Linkerd.
Но если вы уже в Kubernetes и растёте — начните готовиться заранее.

С вами был Георг Гаал.
Пишите в комментариях, что думаете про Service mesh, какие решения пробовали и с какими подводными камнями сталкивались.

? Хотите освоить Service mesh на практике?

Приходите на курс «Service mesh» от Слёрма. Это интенсив, где вы не просто познакомитесь с технологией, а развернёте её, научитесь управлять трафиком, строить политики, внедрять трейсинг и обеспечивать безопасность.

Без воды. С экспертизой. С продакшен-опытом.

Service mesh жил, жив и будет жить. До встречи!