Зачем мигрировать с Istio Sidecar на Ambient, если у вас всё хорошо

Вот важная новость с фронта ИИ: ilia_peskovatskov 10 минут назад Зачем мигрировать с Istio Sidecar на Ambient, если у вас всё хорошо 9 мин 248 Блог компании Альфа-Банк DevOps * Kubernetes * Системное администрирование * Что за Istio, так ещё и в двух режимах, и зачем оно нам надо? Вероятно, вы уже много раз читали про Istio и service mesh на habr или в других источниках, так что у кого уже аллергия, можно переходить к разделу «Миграция». А кому интересно кратко опишу.

В кластерах k8s без Istio один сервис общается с другим напрямую, а в случае сбоя сервис должен сам обработать его: предпринять новую попытку, предусмотреть timeout, открыть circuit breaker и т. Минимизация сбоя это хорошо, но безопасники не спят и хотят, чтобы все было секьюрно: сервисы общались по mtls и проходили аутентификацию и авторизацию. А SRE и DevOps хочет наблюдать за запросами между сервисами: метрики и трассировки.

Технические детали

И конечно у разработчиков нет времени на доработку сервисов (а их может быть много, как и команд развития), так как бэклог бизнес-задач забит под завязку. Здесь появляется Sidecar, через который будет идти весь трафик между сервисами. Istio предлагает специализированное решение, полностью отделенное от сервисов и функционирующее путём вмешательства в сетевое взаимодействие.

И таким образом оно реализует:Отказоустойчивость: опираясь на код статуса в ответе, оно понимает, произошел ли сбой в запросе, и выполняет его повторно. Канареечные выкаты: перенаправляет на новую версию сервиса лишь фиксированное процентом число запросов. Мониторинг и метрики: за какое время сервис ответил?

Трассировка и наблюдаемость: добавляет специальные заголовки в каждый запрос и выполняет их трассировку в кластере. Безопасность: извлекает JWT-токен, аутентифицирует и авторизует пользователей. Вот так, без доработки кода сервисов, мы можем закрыть множество «хотелок» различных подразделений, раскатив пару новых компонентов.

Отраслевые последствия

Мы с помощью Service mesh решали разные проблемы: метрики и трассировка, фичи на выходе из кластера (Service Entry), выполнений требований наших безопасников (PeerAuthentication и AuthorizationPolicy). 2) «Необходимо реализовать внутрикластерную аутентификацию микросервисов» реализуется через mtls посредством service mesh и его CA (PeerAuthentication). Или условие (пункт 3.

1) «Должно быть включено повсеместное использование шифрования TLS (версии не ранее 1. 2) между компонентами кластера и рабочей нагрузкой (микросервисами) между собой», — реализовали приоритетным использованием mtls и service mesh (PeerAuthentication)До отказоустойчивости и других фишек мы не дошли, но всё впереди :)Вы, вероятно, сразу заметили оверхед, которым мы платим за такие функции. А именно ресурсами на каждый такой Sidecar и latency (так как появляется новое звено в прохождении трафика).

В интернете можно встретить цифры 1-3 мс latency и 50-100 мб RAM и 0.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.