Зачем мы делаем Enterprise Service Mesh

[Ktulhy]

А будут технические подробности?
Очень хотелось бы услышать о том:

• На чем написано, какие технологии используются
• Как происходит обновление стека
• Я правильно понимаю, что очередь задач тоже распределённая?
• Как система реагирует на отказ части подов
• Как самооптимизируется (выявляет узкие места? Считает производительность? Смотрит на пинги? Анализирует сетевую инфраструктуру?)
• Какая вычислительная мощность и сколько ресурсов тратится "в воздух" (на обслуживание работы системы)
• Можно ли соединить две такие развернутые подсистемы в одну?

Буду очень признателен за ответ!

[chudnovskiy]

Технических подробностей будет много, пока планируем осветить эту тему отдельным постом.

Если кратко, то

• в основном используется open source, все компоненты распределенные и запускаются в среде управления контейнерами;
• отказы обрабатываются стандартными средствами Kubernetes-кластеров;
• для оптимизации на уровне data plane собирается набор метрик, в плане производительности overhead за счет использования дополнительного уровня proxy конечно есть, конкретные цифры могут быть сильно разными в зависимости от ситуации (степень декомпозиции решения на микросервисы, количество подов, нагрузка и прочее);
• Service Mesh поддерживает мультирежим, причем с различными вариантами топологии data plane и control plane. Например, могут быть два Service Mesh в федерации Kubernetes из двух кластеров, управляемые единым contol plane.

[727digital]

Как помогает Service Mesh для сглаживания проблем с серверами, СХД, сетью? Проводили ли деструктивные тестирования?
Насколько увеличились накладные расходы при внедрении данного решения?
Насколько усложнилась поддержка платформы контейнеризации в целом?

[chudnovskiy]

Частично от проблем с инфраструктурой изолирует сама платформа контейнеризации за счет динамически создаваемых подов, service discovery и т.д. Service Mesh в свою очередь позволяет повысить уровень resilience распределенного приложения без дополнительных затрат: например, на уровне прокси можно управлять политиками retry и timeout management или настроить circuit breaker. Все эти решения пилотируются, в дополнение на уровне Service Mesh можно сделать fault injection и без вмешательства в код приложения проверить, что произойдет с решением в случае реальных сбоев в распределенной среде.

Рост накладных расходов очень сильно зависит от конкретной ситуации, например latency может изменяться от сотен микросекунд до единиц миллисекунд в разных проектах.

В плане сопровождения за счет единого control plane мы получаем возможность управлять всем сетевым трафиком в кластере, в условиях большого числа микросервисов это очень полезно.